Re: changelog bug-closing should not be used unless the code changes
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
Reply to: