Craig A. Berry wrote:
I've checked in the hunk that is a bug fix for do_tovmsspec() as
#25759. Thanks.
The exit handling parts of the patch seem like mostly the right thing
to do and should be applicable with a bit of clean-up and minor
changes. I've tested it under Mac OS X and it introduces no test
failures so we're good from that standpoint.
A few remarks on the patch and related matters in no particular order.
At a minimum, the documentation of C<$?> and C<$^E> in perlvms.pod
and the C<exit> entry in perlport.pod will need updating.
I plan to do so, but I was waiting to have a documented method of seeing
if Perl was in the "posix exit" mode and a method to put Perl in that
mode either before it is run, or optionally while it is running.
The vmsish pragma does not seem to be the right place to force/query if
how Posixish that Perl is in.
When Perl is spawned as a child by GNV Bash it needs to be in that mode
or Bash scripts will not get the expected error status.
I have put in a suggestion for a DCL lexical on future VMS to decode the
POSIX status code out of a VMS status code so that DCL procedures can
also better work with programs written for UNIX and to get this better
documented.
If it will help, I can take a pass at those two files and see what I can
do to bring them more up to date, and to add a "futures" section.
I won't be checking in code that is commented out. If it's not ready
for prime time then we shouldn't clutter up the sources with it, and
if we need to get back to an older version later, that's why we've
got version control.
It is only an issue if errno values greater than 255 ever show up. They
are up to 87 now. I saw some other postings where the offset for the
child status was something other than 8 and only available from system
supplied headers, and so looked up how to properly calculate it from the
existing header information.
What it is documenting is what should be done instead of assuming an
offset of 8, and may be portable to non-VMS platforms as it is using BSD
header values.
I'm not sure perl.h is a good place for a longish discussion of VMS
condition codes. In fact I'm rather sure it's not. This should probably
be in perlvms.pod or perlport.pod and the comments in the code should
just point to that.
I put them in there because apparently to help VMS out, this code has
been changed twice in ways that break VMS in just the last few months.
At 1:49 AM -0400 10/14/05, John E. Malmberg wrote:
+ * vaxc$errno is only suppose to be valid if errno == EVMSERR, otherwise
+ * it's contents can not be trusted.
That's what the CRTL does, not what Perl does. There are many, many
cases where we set vaxc$errno even when errno is not EVMSERR. The
documented behavior of $^E depends on that. Obviously there is no
guarantee vaxc$errno will always have something interesting in it,
but as far as I know it's always either set appropriately or cleared
(by both the CRTL and by Perl) so there is no danger of getting a
stale, unrelated value. I think we should be careful that calls to
unix_status_to_vms() do not wipe out potentially more precise values
that may already be in vaxc$errno.
Calls to unix_status_to_vms should not change the errno value. It does
an imprecise test to see if vaxc$errno is likely to produce the same
value as the unix status currently has, and if so, returns vaxc$errno.
And the only caller of unix_status_to_vms is STATUS_UNIX_SET which is
used when internally Perl wants to override the current setting of
errno, and presumably the native status otherwise.
Also vaxc$errno and errno are thread specific and that does not appear
to be the case for PL_statusvalue_vms or Pl_statusvalue.
Actually what I think maybe should be looked at is to start using
PL_statusvalue_vms instead of trying too hard keep vaxc$errno up to
date. Too many things can change vaxc$errno with out notice.
Until we are sure that PL_statusvalue_vms is being used properly, we
should also update vaxc$errno when Pl_statusvalue_vms is updated.
That is what the STATUS macros in Perl do now. That also means that
instead of checking vaxc$errno in Perl_my_failure(), it should be
checking Pl_statusvalue_vms instead. Much less risk.
That is the same reason to use Pl_statusvalue instead of errno when we
want to keep track of a status value.
Only if PL_statusvalue_vms is -1 or 0, would that mean that it can not
be trusted and we need to fall back to trying to depend on vaxc$errno.
This whole issue really needs more attention, as the concept of trying
to convert from UNIX errno values to a platform native value does not
work unless there is a 1 to 1 relationship, or even a 1 to many.
And with the case of VMS native to UNIX errno, it is a many to many
relationship.
+
+ /* Fixme: Per official UNIX specification: If pid = 0, or negative then
+ * signals are to be sent to multiple processes.
+ * pid = 0 - all processes in group except ones that the system exempts
+ * pid = -1 - all processes except ones that the system exempts
+ * pid = -n - all processes in group (abs(n)) except ...
+ * For now, just lie and say the user has no privileges.
+ */
+
+ if (pid <= 0) {
+ errno = EPERM;
+ vaxc$errno = SS$_NOPRIV;
IMO this should be
SETERRNO(ENOTSUP, SS$_UNSUPPORTED);
Yes, but the ENOTSUP is not listed as an expected error code for kill.
EPERM is the closest one. Technically the privilege is hardwired denied
until someone writes the missing code.
But if ENOTSUP is ok with the Perl programmers, it is ok with me. :-)
Currently vms_status_to_unix() and unix_status_to_vms() both know how to
translate ENOTSUP back and forth to SS$_UNSUPPORTED.
Are there any Perl scripts that actually use negative or zero pids?
I do see Unix code that expects kill(pid,0) to work though so I expected
that feature to be potentially useful in Perl scripts.
-John
[EMAIL PROTECTED]
Personal Opinion Only
