Kamil Dudka wrote:
OK, but this shouldn't be a problem with any applications currently
using close_stdout. At least, none of the applications I know about.
How would you know if they did?
The usual way: ordinary users would be complaining. By "ordinary users" I mean
users other than developers who are employing unusual compiler options,
LD_PRELOAD settings, etc. for testing.
As long as you link libraries dynamically, any of the directly or indirectly
linked libraries can introduce an ELF destructor or atexit() handler anytime,
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.
If we want Coreutils and similar programs to be robust even for developers with
unusual configurations for testing, I expect we'll need to change the programs
to not use the closeout module at all. This would complicate these programs,
since we'd need to check every way that every stdin-reading or stdout- or
stderr-writing program can exit normally, and modify the affected programs to
check the relevant I/O streams just before the normal exit occurs.
