This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH v1.1][BZ #15362] Correctly return bytes written out in _IO_new_file_write


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]