bug-make
[Top][All Lists]
Advanced

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

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


From: h.becker
Subject: Re: vms argv[0] and exit status fixes.
Date: Mon, 24 Mar 2014 21:07:51 +0100
User-agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130519 Icedove/17.0.5

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.

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().

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.

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.



reply via email to

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