[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: vms argv[0] and exit status fixes.

From: John E. Malmberg
Subject: Re: vms argv[0] and exit status fixes.
Date: Tue, 25 Mar 2014 07:47:17 -0500
User-agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3

On 3/24/2014 3:07 PM, h.becker wrote:
There are several problems with the checked-in old exit handling, which
aren't resolved by the recently suggested new code.

Old problems are:
- the %NONAME-?-NOMSG messages, which are generated by VMS when a
program returns a Unix style exit code; an exit code 2 shows as
%NONAME-E-NOMSG, Message number 00000002.
- VMS style warnings do not stop make.

New problems are:
- redirecting exit (and _exit, which seems wrong) to vms_exit, where the
passed exit code is adjusted, doesn't really know whether this is a make
exit code or one passed from an action routine, which can be of any style
- in case of an error there are error numbers printed by make, with the
adjusted exit codes, these numbers are no longer obvious.

That is because the conversion is not complete, only the parent handling has been fixed, not the child status.

Documented Make exit codes are 0, 1, 2 and VMS style exit codes are 0 for success, and VMS style failure codes start at 8 for Access violation.

The CRTL decc$exit() and decc$_exit() are already doing a translation of exit code 0 to be SS$_NORMAL.

So 0 is passed through to decc$exit, and codes 1 through 7 need to be encoded as POSIX exit codes.

And after looking at how MAKE_TROUBLE works, as you had it, it does need to have an ERROR severity level. A warning status should stop the make, but since the target actually got created, re-running make should continue. Since MAKE_TROUBLE is returned when a target is not created, re-running the make should result in a failure again.

I am now able to run the complete test suite, and while not everything passes, I can now see the impact of using the POSIX encoding is, and where more adjustments are needed.

For programs that never see VMS status codes, the _POSIX_EXIT macro definition fixes almost everything. But we can not use it on GNU make because we need the VMS exit codes and want the VMS severity codes for backwards compatibility.

I have not submitted my latest exit handling patch because I am waiting for the GNU copyright assignment. It has been a week now, and I have not seen a response.

It seems that having VMS specific codes for MAKE_SUCCESS, MAKE_TROUBLE
and MAKE_FAILURE is the way to go. Easy, as long as these codes
are always used. But there are hard coded numbers 0, 1 and 2 as well as
EXIT_FAILURE, passed to die() and/or exit().

That may introduce other problems if Make or a child is using the hard coded number instead of the symbol.

It is safer to have the exit() do the encoding, and that is more transparent to majority of the maintainers to make.

The less VMS specific code they have to work around, the better. And the less chance that they may break something VMS specific by accident.

So I suggest to always use the MAKE_mumble macros and to define them for
VMS as posix compatible exit codes. This avoids redirecting exit to
vms_exit; this assumes that the exit status of a child process is VMS
style, which makes checking for failure simpler; this allows to decode
and print the known make error numbers.

If we were compiling /DEFINE=_POSIX_EXIT, then all this happens magically, except then we can not set the VMS severity bits.

But it doesn't solve everything. The usual action routines will be VMS
utilities which set the VMS style exit codes. Any program which adheres
to the VMS style exit codes will work as an action routine as well. That
includes all programs which make use of the posix compatible exit codes
as well.

Action routines, which just return a Unix style number, would need
different checks. Although it seems simple to check for zero (when there
is no VMS facility code set), it turns out that the child processes, as
they are implemented today, never ever return zero. This way it is not
possible to find out whether it was successful or not.

That is already being handled in the lib$spawn. lib$spawn is returning the VMS status in a VMS specific variable, so the VMS status which includes POSIX encoded status.

There is some extra handling needed in the VMS specific code around LIB$SPAWN to decode the POSIX status back to the original UNIX code. That will make the numbers reported by Make look like they should. Once that is done, then the original UNIX constants for MAKE_<mumble> will match the output.

The only case that is problematic to handle is when a child utility ported from Unix using UNIX exit codes is not compiled with /DEFINE=_POSIX_EXIT/MAIN=POSIX_EXIT. In that case, 0 and 1 are both treated as 1, and the rest of the numbers get passed through.

I have been through this conversion on the VMS Perl project which has similar backwards compatibility issues.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]