Re: another gawk 3.1.2 bug

[Aharon Robbins]

> To: Aharon Robbins <address@hidden>
> Cc: address@hidden, address@hidden
> Subject: Re: another gawk 3.1.2 bug
> From: Paul Eggert <address@hidden>
> Date: 28 Apr 2003 09:33:04 -0700
>
> Aharon Robbins <address@hidden> writes:
>
> > 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.
>
> No, when you're closing a pipe, the appropriate primitive is 'pclose'
> (or equivalent), not 'close'.  This is for the same reason that, if
> you are closing an ordinary file that you opened via stdio, the
> appropriate primitive is 'fclose', not 'close'.

Yes, I know that. But the gawk internals are not so simple. Pipes opened
for print/printf use popen/pclose and stdio for output buffering. Pipes
opened for getline and regular input data files use file descriptors and
read(2) directly, for efficiency.  Thus, an awk-level close() on an output
file returns the value from pclose/fclose, while close() on an input
pipe uses wait and close(2).

> That is why Kernighan's awk simply returns pclose's result for pipes,
> and fclose's result for ordinary files.  This clearly conforms to the
> POSIX standard.  Therefore, you needn't change gawk's behavior if
> POSIXLY_CORRECT is set.
>
> If you're still not convinced, I can submit an official interpretation
> on this point, but I'm positive that the answer will come back "yes".

I am still not convinced, so an official interpretation would be welcome.
In particular, some statement as to the meaning, if any, of the return
value when closing input and output pipes would be very helpful, or an
explicit "awk shall behave as if fclose() was called for files and as
if pclose() was called for pipes".

Thanks,

Arnold