Re: fflush & close behavior not well-defined

[arnold]

Hi.

Thanks for the report. Gawk's close already takes an optional second
argument ("from" or "to") for closing one end of a two-way pipe.

If you're willing to hack on the code a bit, I'd have it search the
full list, and upon finding a second instance of the same string,
close it also, but with a warning message.

Otherwise, I think that:

> Or we could just punt and pretend that nobody ever noticed this.

Is the right answer.

Thanks,

Arnold

"Andrew J. Schorr" <aschorr@telemetry-investments.com> wrote:

> Hi,
>
> The close and fflush functions take a string argument indicating
> which file or pipe or coprocess to close. But this may not be a
> unique identifier. Consider this silly program:
>
> BEGIN {
>       # redirect output to a pipe to the md5sum program in $PATH:
>       print "hello" | "md5sum"
>
>       # redirect output to a file named md5sum in the current directory:
>       print "junk" > "md5sum"
>
>       # which file descriptor gets flushed and closed:
>       # the file or the pipe or both?
>       print "flushing and closing"
>       fflush("md5sum")
>       close("md5sum")
>       print "after flush and close"
> }
>
> By studying the source and using strace, one can learn that only the most
> recently opened file will be the one operated on by fflush or close. So these
> operations are not actually well-defined. 
>
> One could in theory add an additional optional argument to these functions
> that specifies what type of file is being sought. For example
>    fflush(<filename>, [<filetype>])
> where filetype is one of ">", "|", or "|&". That would match the way
> this information is stored internally in the red_head list in io.c.
>
> Or we could document that this is nondeterministic. Or we could just
> punt and pretend that nobody ever noticed this.
>
> Regards,
> Andy