Re: Undetected fatal errors from redirected print

[Andrew J. Schorr]

Hi Miguel,

To be clear, I did not come to any conclusion. I was merely pointing
out a few considerations:

1. The more typical case where an open fails does result in a fatal error.

2. If an error occurs in a write call after the open succeeded, I can
imagine two causes: a filesystem filling up, or it's a write to a pipe
or socket where the other side has shut down. The full filesystem case
is pretty unusual, and I'd argue that if you're messing with pipes or sockets,
you should probably take care to check the return codes from close. Maybe
there are other scenarios that I'm missing. Do you have something in mind?
Is there a particular usage case that got you in trouble?

3. I wanted to point out the comment in the code that I mentioned previously:
                /*
                 * BWK's awk, as far back as SVR4 (1989) would check
                 * and warn about the status of close.  However, when
                 * we did this we got too many complaints, so we moved
                 * it to be under lint control.
                 */
I don't know who was complaining or why, so I don't know what the
counterarguments are. I'm generally in favor of reporting errors, but I
guess there must be some people who don't like that behavior.

4. You have the option of running with --lint if you'd like to see more
warnings, but that may also have its drawbacks.

All that said, I defer to Arnold.

Regards,
Andy

On Tue, Nov 23, 2021 at 01:30:09PM -0500, Miguel Pineiro Jr. wrote:
> Hi, Andy and Arnold.
> 
> I disagree with your conclusion. Before I drop the matter, allow me to 
> reframe the problem, because I think the fact that the situation involves the 
> closing of streams has muddied the waters. For the moment, let's forget about 
> fclose(3), close(2), close_rp, and close_redir; instead let's focus on the 
> print statement.
> 
> The GNU Awk User’s Guide, 5.10 Enabling Nonfatal Output:
> "In standard awk, output with print or printf to a nonexistent file, or some 
> other I/O error (such as filling up the disk) is a fatal error."
> 
> efwrite handles the actual printing for print and printf. efwrite correctly 
> dies when writing fails. However, because of buffering, efwrite sometimes 
> doesn't even attempt to write. It simply stores the data and returns success. 
> If the quote from the user's guide is correct, returning success without 
> writing the data is a promise to die in the future if the data cannot be 
> written.
> 
> Thank you both for taking the time to consider my report,
> Miguel