|
From: | Paul Eggert |
Subject: | Re: Why does close_stdout close stdout and stderr? |
Date: | Sun, 12 May 2019 18:09:59 -0700 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 |
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.
[Prev in Thread] | Current Thread | [Next in Thread] |