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.
> ...
> When these rules are followed, regardless of the sequence of
> handles used, implementations will ensure that an application, even
> one consisting of several processes, will yield correct results: no
> data will be lost or duplicated when writing, and all data will be
> written in order, except as requested by seeks. It is
> implementation-dependent whether, and under what conditions, all
> input is seen exactly once.
>
> For this be true, it must also be true that no data will be lost when a
> command line like the following is executed, and the file system is full:
>
> $ command blah blah... >file
>
> For example, the program could wait (presumably in select()) if the file
> system was full when trying to exit() with non-empty buffers.
No, the function returns ENOSPC, and the program is left to deal with
handling the failure. 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.
> 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.
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.
--
-----------=======-=-======-=========-----------=====------------=-=------
/ Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \
` bcollins@debian.org -- bcollins@openldap.org -- bcollins@linux.com '
`---=========------=======-------------=-=-----=-===-======-------=--=---'
Reply to: