Re: another gawk 3.1.2 bug

[Aharon Robbins]

Paul,

> To: Aharon Robbins <address@hidden>
> Cc: address@hidden, address@hidden
> Subject: Re: another gawk 3.1.2 bug
> From: Paul Eggert <address@hidden>
> Date: 27 Apr 2003 22:49:34 -0700
>
> Aharon Robbins <address@hidden> writes:
>
> > POSIX simply says that the return value is 0 for success, non-zero
> > otherwise, indicating that there is no way to gain access to the various
> > bits of info.  I will probably make this the case for POSIXLY_CORRECT,
> > and leave things as is otherwise.
>
> Sorry, I don't follow.  gawk 3.1.2 already conforms to POSIX here, as
> did gawk 3.1.1 (in a different way).  So I don't see why
> POSIXLY_CORRECT should affect gawk's behavior here, unless you're
> thinking of having gawk behave a third way by default, a
> non-POSIX-compliant way that is different from both 3.1.2's way and
> 3.1.1's way.  But surely you're not thinking of doing that.
>
> > I note that Brian Kernighan's awk acts like the current gawk; mawk
> > acts like 3.1.1.  I don't know what The Right Thing To Do is, nor do
> > I see a clean way to make everyone happy.
>
> I tend to think that Kernighan's awk (which is the original, and which
> is still a live implementation) should outweigh mawk (which seems to
> be dying if not dead).
>
> One possibility would be to give gawk users the whole WEXITSTATUS /
> WIFEXITED / etc. set of macros.  This sounds a bit extreme, though.

Yep.  I won't do that.  It can be done as awk functions if one is
willing to assume a fairly common layout of bits in the exit status.

> If we had to do it over again, I'd say that system() should return the
> full 16 bits too, for consistency with close().  I suppose it's too
> late for that, though.

Here's the text of the 2001 standard:

    close(expression)
        Close the file or pipe opened by a print or printf
        statement or a call to getline with the same string-valued
        expression. The limit on the number of open expression arguments
        is implementation-defined. If the close was successful, the
        function shall return zero; otherwise, it shall return non-zero.

Interpreting this depends upon what it means to "close successfully".
Gawk successfully does a close(2) on the file descriptor(s) and a wait(2)
on the child process.  Thus the *act of closing* succeeds, and in this
case, *as I read the standard*, it should return 0.  That the child
died due to a signal or explicitly exited with a non-zero value does
not reflect the success/failure of the awk-level close() operation.

OTOH, if the awk program does   close("/some/file/that/was/never/opened")
then I deem that as an unsuccessful close and return -1.

Thus, if POSIXLY_CORRECT is in force, when the close operation succeeds
it returns zero; if not POSIXLY_CORRECT, it returns the 16-bit exit
value of the child.

The standard is quite silent (purposely or otherwise) about accessing the
exit value of the child program spawned for the pipe.  (Undoubtedly this
is something worth trying to fix down the road for the next revision;
I personally don't have the energy to pursue this, though.)

Arnold