Re: Why does close_stdout close stdout and stderr?

[Paul Eggert]

On 5/13/19 12:00 AM, Florian Weimer wrote:
> > I don't see any way around this problem in general with the closeout
> > module's current API, because when it discovers an I/O error it calls
> > _exit, and _exit also clashes with that kind of cleanup handling.
> This isn't the problem.  fflush may also realistically cause SIGPIPE to
> be delivered to the process.  That's all fine.

It might be fine for some of these environments, but surely it can't be 
fine for others. If I'm relying on the startup routines to issue some 
sort of report for any non-signalling exit, then calls to _exit will 
bypass the report.

> Look at the existing workaround
> for sanitizers, and the comment in close_stream.  The code is buggy

I agree the code is a hack. But it's not buggy: it's portable to any 
environment that conforms to POSIX, and that's a wide variety of 
environments. The problem seems to be that people want to run these 
applications in debugging environments that don't conform to POSIX. 
While I'm sympathetic to that goal, it's not a high-priority-enough 
situation to call the current code "buggy".

A better fix here would not be to pile yet another hack into this hacky 
module. It would be to write a better module (we could call it 
"flushout", say) that would define a function ("flushout_stream", say) 
that would act like fflush but would do a better job with NFS-based 
streams by playing the dup+close+fsync trick. We could then modify 
coreutils etc. to use this new module instead of the old one. The hard 
part is the "modify coreutils etc." part, because flushout_stream will 
be less convenient to use than the current API.