On Tue, Jan 02, 2001 at 07:52:31AM -0500, Raul Miller wrote: > > Ben: I think you should re-open this bug. > > > > Single Unix Specification says: > > [http://www.opennc.org/onlinepubs/7908799/xsh/stdio.html] > > > > A handle which is a stream is considered to be closed when either > > an fclose() or freopen() is executed on it (the result of freopen() > > is a new stream, which cannot be a handle on the same open file > > description as its previous value), or when the process owning that > > stream terminates with exit() or abort(). A file descriptor is > > closed by close(), _exit() or the exec functions when FD_CLOEXEC is > > set on that file descriptor. ...
On Tue, Jan 02, 2001 at 11:39:09AM -0500, Ben Collins wrote: > No, the function returns ENOSPC, and the program is left to deal with > handling the failure. The exit() function fails to return ENOSPC under this condition. Nor does SUS permit it to do so. > In that case, no data is lost, because the program is told about it. > When working with streams (stdout being a buffered stream), you must > take into account the buffering. IOW, if you want to ensure that the > buffer is empty, call either fclose, or fflush, and check the return > of that call. Or you can setbuf() so that it is unbuffered and errors > are seen immediately. I'm talking about what exit() does, when it can't can't flush stdout. What are you talking about? > > Exiting without writing the data [and even more, without providing a > > failure notice] is clearly a violation of this standard. > > Yes, that is an error in the program, not libc. It is up to the program > to check return values, and to act accordingly to errors. By your > convention, doing: > > fprintf(fs, "blah"); > fclose(fs); > > should cause the program to fail on a full filesystem, even though the > program did not explicitly check the return values. That is incorrect. I don't see anything in what I said which says anything like this. > The program *must* check if it considers this important. A program > that exits without checking it's stream buffers is assumed to not care > about them, because if it did, it surely can handle checking these > before exit, without libc intervention. Please show me the part of the standard which indicates that this is true for the case of the defined implicit handling of stdout. -- Raul
