This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v1.1][BZ #15362] Correctly return bytes written out in _IO_new_file_write
- From: Siddhesh Poyarekar <siddhesh dot poyarekar at gmail dot com>
- To: Eric Biggers <ebiggers3 at gmail dot com>
- Cc: Siddhesh Poyarekar <siddhesh at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>, "Carlos O'Donell" <carlos at systemhalted dot org>, "Joseph S. Myers" <joseph at codesourcery dot com>
- Date: Mon, 15 Apr 2013 11:47:25 +0530
- Subject: Re: [PATCH v1.1][BZ #15362] Correctly return bytes written out in _IO_new_file_write
- References: <CAAHN_R2FdXBd8869PksUgiM0KFGPJfnnwssucOGL9t9s9k67ow at mail dot gmail dot com> <20130415060209 dot GA2313 at zzz dot student-wireless02 dot macalester dot edu>
On 15 April 2013 11:32, Eric Biggers <ebiggers3@gmail.com> wrote:
>> When the write fails, it sets ERR_SEEN. Here, a zero or partial write
>> is implied to be either an error or EOF, so the application is
>> expected to call ferror or feof to check which one it is.
>>
>
> I thought that the EOF condition (as tested through feof()) was only meaningful
> for reading.
You're right - I need to pay more attention. ferror if there's a
short write. ferror or feof if there is a short read.
> I was thinking that fwrite() is supposed to accept as much as the provided data
> as it can without violating the requested buffering semantics. So if a single
> line of length n including the newline fails to flush, but it still fits in the
> buffer, the first n - 1 bytes should still be kept and that would be the return
> value. This may sound like it's abusing the buffer, but this would match what
> would happen if fputc() were to be called n times as the C standard suggests:
> the first n - 1 calls would succeed but the nth would fail, so the return value
> would be n - 1 bytes written.
Hmmm, then case of your earlier point of returning the full length vs
returning zero for an input ending with newline, perhaps the return
value should again be n - 1, excluding the newline.
> Hmm, I'm confused by _IO_wfile_xsputn() though. Like _IO_new_file_xsputn(),
> there's a comment that claims it is an optimized implementation that uses
> sys_write() directly when possible. But the actual code doesn't appear to do
> that, as it just copies some of the data into the buffer and calls
> _IO_wdefault_xsputn(), which appears to also handle copying data into the
> buffer...
If there's a conflict, then the comments must be lying. Nobody cared
to update them in the past (which is wrong). I had tried to fix up a
few when I made some changes here last year, but they're still not in
good enough shape. This is especially true for *.c and their widechar
companions since the latter was copied and adjusted from the regular
source, with comments not always updated.
Siddhesh
--
http://siddhesh.in