[Top][All Lists]

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

Re: fflush & close behavior not well-defined

From: Lorenz
Subject: Re: fflush & close behavior not well-defined
Date: Tue, 15 Sep 2020 06:59:27 +0000

Hi all,

would gawk warning about such ambiguitiies be an option? At least in
--lint mode?


Andrew J. Schorr wrote:
>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:
>       # 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.

reply via email to

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