| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
| |
fakethr.h and FAKE_THREADS were for a "green" threads implementation of
5005threads. 5005threads itself is long gone, and it's not clear that
-DFAKE_THREADS *ever* built correctly. Certainly it did not work for the
5.005 release, and it did not work at the time of the commits for the initial
checkin. The closest that it seems to have been to working is around commit
c6ee37c52f2ca9e5 (Dec 1997), where the headers no longer contained errors,
but perl.c failed to compile.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Happy 20th Anniversary, Charles.
|
| |
|
|
|
|
|
|
|
|
|
| |
The CRTL's fstat() sets errno to EVMSERR and vaxc$errno to RMS$_IOP
when called on a proccess-permanent file (i.e., stdin, stdout, or
stderr). That error generally means a rewind operation on a file
that cannot be rewound. It's odd that fstat is doing such a thing,
but we can at least protect ourselves from the effects of it by
saving errno and restoring it on a successful call.
This cures a couple of test failures and TODOs in t/io/errno.t.
|
| | |
|
| |
|
|
|
| |
And while we're there, set errno appropriately for the empty string
input case.
|
| | |
|
| |
|
|
|
|
|
| |
The macro used in vms/vms.c for errors from native calls deemed
too severe to handle was calling fprintf without checking return
values, which caused a huge pile of warnings when compiling with
/WARN=ENABLE=LEVEL5. So suppress those warnings with a void cast.
|
| | |
|
| |
|
|
|
|
| |
Since we now enable some features that are not the CRTL's defaults,
we should allow them to be explicitly disabled in the environment
if someone wants the old behavior.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This feature has been available for over a decade but is still not
the default for the CRTL. It seems time to make it the default
for Perl. It means that directory names can have dots in them,
and filenames can contain multiple dots as well as spaces and
generally characters from the top row of the keyboard while the
shift key is held down.
Filenames with native syntax must escape characters in the so-called
extended character set with a caret ("^"), but filenames in Unix
syntax must not have the escapes. Conversions between native and
Unix syntax will, respectively, add and remove these escapes.
Supporting Unicode in filenames depends on this feature but has
not yet been investigated.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We've been making our home-grown readdir implementation convert
all its results to Unix format since a096370a74e8. Since readdir
returns relative paths, the usual volume and directory syntax
differences that distinguish VMS and Unix paths don't really apply.
But what does apply is whether the escaping of extended characters
is passed through or removed, and converting to Unix syntax removes
those escapes. In order to enable extended filename syntax, though,
we're really going to need the escapes. For example, rmdir will
not be able to remove a directory foo.bar if it's referred to as
[.foo.bar] because a dot is the traditional directory delimiter.
The directory needs to be specified as [.foo^.bar] for rmdir to
delete it successfully.
So make readdir return filespecs in native format unless explicitly
requested to report all filenames in Unix format.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Sometimes filename components get pasted together in ways that put
a component with caret escapes proper to Extended Filename Syntax
(EFS) for native filespecs into a Unix-format filespec. An example
would be /a/b/foo^_bar, where the '^_' sequence indicates a space
in a native filespec but is technically invalid in a Unix
filespec.
But it doesn't really cost much more to remove the escapes since
we're copying the whole string anyway, so go ahead and do that.
This could theoretically cause trouble if we get Unix-format paths
that have literal carets in them, but that theoretical trouble is
currently less troubling than the practical trouble that crops up
various places in the test suite if we don't do this.
|
| |
|
|
|
|
|
|
|
| |
When converting VMS format file specification to Unix format, we
need to translate sequences escaped with a caret in the VMS format
name into an unescaped form in the resulting Unix name. We have
a function to do just that, but weren't using it in three of the
most important places that need it. Using the function gets us
handling more cases than the simple versions we had inline.
|
| |
|
|
|
|
|
|
| |
This feature was apparently intended to enable workarounds for
handling filespec translations on paths with no directory component.
Many (most?) of the problems with such paths have now been fixed,
and the feature itself was never actually used, so we're better
off without it.
|
| |
|
|
|
|
|
|
|
| |
This is a partial retreat from b3efb2487fa7, where we started
passing through all ambiguous filespecs without modification. We
can now process the majority of cases that aren't macros, following
59247333b91 and various other commits that improved the escaping
of dots. So for now we'll attempt to process these and pass
through macros only.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We've been assuming there is always a directory portion to a path
being converted to VMS format, and it's true that translating
directory delimiters and such is the most noticeable aspect of
such conversions. But we also depend on the conversion to add
caret escapes to characters in the path that are only valid when
using Extended Filename Syntax (EFS), but weren't doing that
for paths with no directory component.
I.e., this was working:
/disk/dir/foo%bar --> disk:[dir]foo^%bar
but this was not (until now):
foo%bar --> foo^%bar
Since we're now working on a pointer that has not necessarily
been incremented while adding directory syntax, we also add
a number of guards to make sure we don't peek beyond the
beginning of the result string.
N.B. There will be a separate commit following shortly that
prevents paths with no directory component from being passed
through as-is -- here we just provide the infrastructure to
make that possible.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
When converting a VMS file specification containing caret escapes
for extended characters to Unix format, we need to remove those
escapes. We were doing so for paths containing directory
components but we also need to do it for bare filenames. I.e.,
this was working:
disk:[dir]foo^%bar --> /disk/dir/foo%bar
but this was not (until now):
foo^%bar --> foo%bar
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
c1abd561a0a322 avoided the double escaping of dots in filenames,
but failed to copy the dot itself in cases where it was already
escaped. Plus, when not using extended file specifications and
thus converting the dot to an underscore, we need to make sure
the underscore is not escaped.
And add a test that covers most of these scenarios. Probably
more tests are needed.
|
| |
|
|
|
|
| |
Since it's impossible to guarantee a filename is never makes
multiple trips through the Unix-to-VMS converter, it's important
not to escape characters that have already been escaped.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When converting a filename with multiple dots to native VMS syntax,
it's necessary to escape all but the last dot with a caret ('^').
We've been doing this for some time, but have been doing it blindly
such that multiple trips through the converter resulted in a
stuttering caret problem (e.g., foo^^^.bar.pl when foo^.bar.pl was
intended).
So create a convenience macro that does the escaping and make it
only escape unescaped instances and also make it check that the
escape doesn't push us off the end of the buffer we are working
on.
Use the new macro in the three most obvious places that it's
applicable. There may be other places that also should use it.
|
| |
|
|
|
| |
After setting the null byte, we turned around and pretended we
didn't know where it was and went hunting for it. Hmm.
|
| |
|
|
|
|
| |
When we got to the end of a directory we were not freeing the
buffer we'd been using. So refactor that section of code to have
only one return. Bug introduced in 657054d4f860463a01c5.
|
| |
|
|
|
|
|
|
|
|
| |
For some reason the omnibus patch (360732b5267d5dfe) that brought
Extended Filename Syntax support to the VMS port considered three
dots part of the filename portion rather than part of the
directory portion when converting a Unix-format path to VMS format.
There's no reason this should be different with EFS, so make it
the same as without EFS, which gets two TODO tests passing.
|
| |
|
|
|
|
|
| |
This finishes the removal of register declarations started by
eb578fdb5569b91c28466a4d1939e381ff6ceaf4. It neglected the ones in
function parameter declarations, and didn't include things in dist, ext,
and lib, which this does include
|
| |
|
|
|
|
|
| |
In readdir and start_glob, we were removing the .DIR extension from
VMS directory names when reporting results in Unix format, but also
when Extended Filename Syntax (EFS) was enabled. The former makes
sense, but the latter (by itself) doesn't.
|
| |
|
|
|
|
|
|
|
|
|
| |
When Extended Filename Syntax is enabled on VMS (which is not [yet]
the default), we were allowing invalid directory specifications
consisting of a .DIR extension but some version other than ;1 to
be passed through.
Now we flag that as an invalid directory just as we were doing
without EFS. This gets a test passing in vms/ext/filespec.t that
was failing under EFS.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The way this file has been getting copied from vms/ext/filespec.t
during the build involves the expansion of the standard macro
MMS$TARGET, a process which caused the name of the copied file to
always end up in upper case.
Before we started preserving case, all filenames were downcased
by readdir(), so .t matched .t and everything was peachy. But
when we started preserving case in Perl on VMS we started silently
skipping this test because .T does not match the pattern we look
for in t/TEST.
So take advantage of the fact that MMS and MMK don't upcase
user-written macros when expanded and use one of those as the
copy target, thus preserving the case of the copied file, which
then matches what t/TEST is looking for.
|
| |
|
|
|
|
|
|
|
| |
When translating filenames from Unix syntax to VMS syntax, there
are some unparseable cases that are best left unchanged. We were
doing this with extended filename syntax turned off, but we still
need it even when extended filename syntax is turned on, such as
for unescaped extended characters in a name that has no directory
delimiters.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
OpenVMS releases of the last decade or so have had this capability
but it's still not the default. But it's a reasonable default for
Perl, so enable it in our initialization code.
Unfortunately this feature does not work unless extended parse has
been enabled in the process before invoking Perl. Enabling
extended parse in our initialization code doesn't do any good
because DCL has already parsed the arguments before we get there.
So we will be limited to documenting that things work better with
extended parse and that the test suite assumes it's enabled.
|
| |
|
|
|
|
| |
Both MMS and MMK upcase whenever there is a double macro expansion,
but by going through only one expansion, we can preserve the case
of the target filename on copy under extended parse.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
VMS systems of the last decade or so have the ability, when
operating on an ODS-5 volume, to preserve filename case. In order
for CRTL calls to make use of this capability, the feature setting
DECC$EFS_CASE_PRESERVE must be explicitly enabled. We now do that
for Perl at start-up time, which depends on latent support that
has been in the core since 5.10 but not quite working until
recently.
Note that case preservation of command-line arguments is not
included in this feature. That's a different setting and is not
entirely under Perl's control as the command line is parsed by
DCL before the CRTL sees it.
|
| |
|
|
|
|
| |
It was in the middle of the includes at the top of the file. Move
it close to its only use and, more importantly, after the includes,
some of which it now depends on.
|
| |
|
|
|
|
|
| |
When setting a CRTL feature, also record the setting in a user-mode
logical name since historically checking the environment is the only
way a Perl program can check a particular setting (otherwise we'd
need the currently vaporware VMS::Feature extension).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
By defining NO_TAINT_SUPPORT, all the various checks that perl does for
tainting become no-ops. It's not an entirely complete change: it doesn't
attempt to remove the taint-related interpreter variables, but instead
virtually eliminates access to it.
Why, you ask? Because it appears to speed up perl's run-time
significantly by avoiding various "are we running under taint" checks
and the like.
This change is not in a state to go into blead yet. The actual way I
implemented it might raise some (valid) objections. Basically, I
replaced all uses of the global taint variables (but not PL_taint_warn!)
with an extra layer of get/set macros (TAINT_get/TAINTING_get).
Furthermore, the change is not complete:
- PL_taint_warn would likely deserve the same treatment.
- Obviously, tests fail. We have tests for -t/-T
- Right now, I added a Perl warn() on startup when -t/-T are detected
but the perl was not compiled support it. It might be argued that it
should be silently ignored! Needs some thinking.
- Code quality concerns - needs review.
- Configure support required.
- Needs thinking: How does this tie in with CPAN XS modules that use
PL_taint and friends? It's easy to backport the new macros via PPPort,
but that doesn't magically change all code out there. Might be
harmless, though, because whenever you're running under
NO_TAINT_SUPPORT, any check of PL_taint/etc is going to come up false.
Thus, the only CPAN code that SHOULD be adversely affected is code
that changes taint state.
|
| |
|
|
|
|
|
|
|
|
|
| |
This routine by its very nature applies to the whole process so
there is no way it can make use of a thread context, and it may need
to be called from places where there is no thread context, such
as very early in start-up.
It's not documented, was never intended to be part of the API, was
only made global so it could be called from doio.c, and no uses of
it turn up in a CPAN grep, so the change should be safe.
|
| |
|
|
|
|
|
|
| |
noexe is the default and older compilers can't process it, so don't
explicitly specify it.
nopic is mandatory but non-default on VAX and is silently ignored
on Alpha and Itanium, so go ahead and specify it explicitly.
|
| |
|
|
|
|
|
| |
The MINIPERL macro expands to 40 characters longer than the
MINIPERLQ macro in order to include Cwd, but Cwd isn't needed
when doing a simple one-liner, and the extra length can make us
exceed the command buffer on older VMS systems.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Because we now have:
#include "../unicode_constants.h"
which is a Unix-style path and cannot be combined with [.x2p] and
get a valid result.
|
| |
|
|
|
|
| |
Otherwise building on VMS with -Dusemymalloc=y fails because we
enter them as procedures in the linker options file and the linker
knows we're lying and will have none of it.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This removes most register declarations in C code (and accompanying
documentation) in the Perl core. Retained are those in the ext
directory, Configure, and those that are associated with assembly
language.
See:
http://stackoverflow.com/questions/314994/whats-a-good-example-of-register-variable-usage-in-c
which says, in part:
There is no good example of register usage when using modern compilers
(read: last 10+ years) because it almost never does any good and can do
some bad. When you use register, you are telling the compiler "I know
how to optimize my code better than you do" which is almost never the
case. One of three things can happen when you use register:
The compiler ignores it, this is most likely. In this case the only
harm is that you cannot take the address of the variable in the
code.
The compiler honors your request and as a result the code runs slower.
The compiler honors your request and the code runs faster, this is the least likely scenario.
Even if one compiler produces better code when you use register, there
is no reason to believe another will do the same. If you have some
critical code that the compiler is not optimizing well enough your best
bet is probably to use assembler for that part anyway but of course do
the appropriate profiling to verify the generated code is really a
problem first.
|
