Eric Blake <[EMAIL PROTECTED]> wrote: > According to Bruno Haible on 8/18/2007 5:12 PM: >>> >>> results in calling close_stdin first. From there, if close_stdin detects >>> an error, there is the potential for stdout/stderr to be unflushed (and >>> thus output data lost) when close_stdin calls _exit. >> >> I would just document that close_stdout and close_stdin are incompatible, >> and that close_stdin_stdout should be used instead of the two together. > > But that brings us right back to where we are today without any patch - > close_stdin currently calls close_stdout in the correct timing, so an > application does either atexit(close_stdin) or atexit(close_stdout), but > not both. > >> You can see that in coreutils, these functions are only used with atexit, >> at exactly one place in main(). The maintainer can statically determine >> whether he needs close_stdin or not, and if so, use close_stdin_stdout. > > So maybe we are back to square one - leave yesno() alone (ie. it should > not install any atexit handler), and instead, document in yesno that any > caller should consider adding atexit(close_stdin) in main. > > Affected programs (list might not be complete): > cp > find > install > ln > mv > rm > > Jim, you are affected the most - which would you rather see, a relatively > big patch to yesno/closein that potentially changes API, or a one-line > patch to each of your five affected programs?
The complexity of the yesno-modifying approach seems too high, and not limited just to yesno, so I think the per-application one-line changes are better.
