| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Back in 8dc9d3390b257b I consolidated two routines that were
almost identical -- except for their return values. The routine
I kept returns the length of the equivalence name after logical
name translation, but some uses of it were checking it to see if
it was a successful VMS condition value. Which means an odd length
(such as from "1") was successful but an even length (such as from
"ENABLE", the value recommended in the documentation) failed. So
fix those uses to check for a non-zero from simple_trnlnm.
For most features this only affected pre-7.3 systems, i.e., VMS
releases more than thirteen years old. However, it also affected
features such as PERL_VMS_POSIX_EXIT that we have made up on our
own and are not tracking a CRTL feature.
(cherry picked from commit 9bd30c63d934b70cf98e71983670d3e837ec38bb)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a follow-up to d5e61aaf9d7051b136, where we stopped
escaping semicolons in tovmsspec when they appeared to be the
beginning of a version specification but always escaped them
otherwise.
It turns out there is yet another CRTL feature logical name
(DECC$FILENAME_UNIX_NO_VERSION) that tells us a Unix-format
specification is not allowed to have a version number, so in
that case, always escape the semicolon since it can't be the
start of a version specification.
Also, don't add the version number when fileifying directory
specs if this "no versions" feature is in effect.
|
| |
|
|
|
|
|
|
|
|
|
| |
In theory, a Unix-format filespec can contain a semicolon and thus
need to be escaped when converted to a VMS-format filespec. But
a much more common use case is a filespec that has a version
number despite being in Unix format.
So detect a semicolon that delimits a version specification and
pass it through but escape other semicolons. This is apparently
what decc$to_vms does, so we're being consistent with the CRTL.
|
| |
|
|
|
|
| |
av_tindex is a more clearly named synonym for av_len, available starting
in v5.18. This changes the core uses to it, including modules in /ext,
which are not dual-lifed.
|
| |
|
|
|
|
|
|
|
| |
In particular, a node specification containing only a single
directory (i.e., node::dev:[dir]) was not being handled properly.
This came up while reproducing the problem in [perl #121002] but
was not the cause of that problem as the OP's directory had
multiple subdirectories in it.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As reported in [perl #121002], the homegrown opendir has been
failing when the directory specification contains a DECNet node
specification indicating the directory to be accessed is on a
remote node. The OP reports this worked with Perl 5.001 but not
5.8.6 or 5.18.2.
It appears that the culprit was the introduction of access
checking to Perl_opendir in 61bb59065bf1b12edab39b12, which would
first have been released in 5.004. Yes, it's been broken for 17
years.
The reason access checking broke remote access is that it's based
on SYS$CHECK_ACCESS, which apparently does not work on remotes,
though the only hint of that in its documentation is that the
status SS$_UNSUPPORTED, "Operations on remote object are not
supported" is listed as a possible return value. What it actually
returns, despite the documentation, is SS$_INVFILFOROP, "invalid
file specification for operation."
The fix is simple enough -- just skip the access check if the
directory name contains a node specification (which always ends
with "::"). All the access check is providing is a friendlier
error message in cases where we don't have access, so no harm is
done by skipping the check in cases where it can't work.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Passing a path to int_tovmsspec that contained an "extended"
character as the first character when converting a Unix filespec
to VMS format skipped escaping that character, but only when the
path spec had no directory component. The character that didn't
get escaped could then be passed to a native service that choked
or incorrectly processed it. For example ' foo.txt' remained,
after translation, ' foo.txt', but parsing that as a native spec
would squeeze out the leading space.
So we now make sure we don't eat the first character of the
filename component while processing the directory component and
also handle escaping the very first character. In the example
of ' foo.txt', it now gets correctly translated to '^_foo.txt'.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a follow-up to e2d6c6fbf5bb. The use case I've seen is
that the translation of SYS$INPUT succeeds but the stat on the
resulting file/device fails, possibly due to object protections.
So we would be giving the child something it can't open.
Add error checking to the logic so in order to set up inheritance
of SYS$INPUT:
1.) The translation of SYS$INPUT must succeed.
2.) stat() on the resulting spec must succeed.
3.) The resulting spec must not be a directory.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The documentation to LIB$SPAWN says that standard input will be
inherited from the parent if not specified, and we've been
depending on that. But it seems not to actually work that way
as a simple
$ perl -e "system('edit foo.tmp');"
was failing due to the input not being a terminal. So set up the
input explicitly using the same mechanism we've always used for
output and error.
Except when SYS$INPUT is a "directory," which probably means it's
a channel open on a volume that holds a command procedure.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
When doing a logical name translation of a process-permanent file
(SYS$INPUT, SYS$OUTPUT, SYS$ERROR, or SYS$COMMAND), we need to
remove the special 0x001b prefix from the translation string
regardless of whether we are combining a search list into a
longer equivalence string or just doing a simple, index-free
lookup.
Since we now have two places needing the same logic, move that
logic into a static inline function.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In a35dcc95dd24524931e I "improved" string safety in vms/vms.c by
converting to my_strlcpy and my_strlcat, but mangled the length
argument to my_strlcat when adding the name of the logical name
table specified in PERL_ENV_TABLES. This caused the command string
to be truncated, so a command that, for example, should have been:
$ Show Logical * /Table=LNM$JOB
...
actually became:
$ Show Logical * /Table=
%DCL-W-VALREQ, missing qualifier or keyword value - supply all required values
Plus it turns out the strings holding the names of the tables were
being stored in dynamic string descriptors and were not
NUL-terminated, but the strl* functions require NUL-terminated
arguments. So change those to static string descriptors and
allocate the exact amount of storage needed including room for a
NUL.
This was a regression in 5.16.0, first reported a couple of days
ago by Mark Daniel on comp.os.vms:
Date: Fri, 06 Sep 2013 12:56:01 +0930
From: Mark Daniel <mark.daniel [AT] wasd.vsm.com.au>
Newsgroups: comp.os.vms
Message-ID: <52294b4a$0$2875$c3e8da3$76491128@news.astraweb.com>
TODO: Figure out how and where to test this.
|
| |
|
|
|
|
|
|
|
|
| |
Make the array interface 64-bit safe by using SSize_t instead of I32
for array indices.
This is based on a patch by Chip Salzenberg.
This completes what the previous commit began when it changed
av_extend.
|
| |
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
C++ insists on casting the return values of the malloc family.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Prior to the current change,
$ foo "A" "b" "c"
worked, but the following didn't:
$ "foo" "A" "b" "c"
%DCL-E-PARSEFAIL, error parsing DCL$PATH:"foo".*
-RMS-F-FNM, error in file name
even if foo was a valid command or path. It's illegal in DCL to
quote the command verb even if it's often necessary to quote the
parameters to it.
But various things in the wild (such as Test::Harness::_filtered_inc),
find it convenient or necessary to quote the command verb, so the
easiest way to support that is to unquote it before DCL sees it, and
that's what this change does.
Also, spaces within the first quoted item are now escaped so that
an image path containing spaces doesn't run afoul of subsequent
tokenizing based on spaces.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The LIB$INITIALIZE program section is examined by the image
activator for an array of 32-bit pointers to functions that will
get called early in start-up, before main() is called. We use
this mechanism to get and set various run-time features.
The implementation we had was a bit cluttered with undocumented
features that weren't being used, and it didn't work under C++.
This new implementation is simpler and follows the documented
usage in the C++ release notes much more closely, and it works
under both C and C++.
We also now explicitly export the LIB$INITIALIZE psect in the
linker options file used to create the PERLSHR shareable image.
|
| |
|
|
|
|
| |
We currently aren't getting any warnings about pragmas that need
to be suppressed and the C++ compiler doesn't know about the
"pragma" class of warnings, so stop disabling them.
|
| |
|
|
|
| |
Unless __DECC was meant as the opposite of VAX C, which is not
C89-compliant and cannot build Perl.
|
| |
|
|
|
| |
We were only using 4K, not 64K, and we were requesting longword
alignment but not providing a struct size that was a multiple of 4.
|
| |
|
|
|
| |
This is a follow-up to c11536f52. Oddly. C++ was ok without the
"struct" but C wasn't.
|
