This is the mail archive of the glibc-bugs@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]

[Bug libc/5742] stdio poor file buffering in "w+b" mode


------- Additional Comments From olivier dot paquet at gmail dot com  2008-02-21 16:22 -------
(In reply to comment #4)
> Is it acceptable to open the file with "wb" instead of "w+b"? This would avoid
> the spurious read.

Not in this case unfortunately. The file is written to most of the time but
there are occasional reads.

> Requesting that a file be opened for update "+" forces the implementation to
> expect that a read *or* write could occur (as per the standard). The
> implementation chooses to fill the stream buffer after the seek.

Yes, I am quite aware of that. It's that algorithm (or choice if you want to
call it that) which is a little simplistic. The implementation could very well
delay filling its buffer until the first read or non-contiguous write. This
would only require a pointer to remember that "the buffer is valid up to here".
A write can push this pointer forward without the need for reading data from the
file. A read obviously needs to get some real data. A small seek which does not
cause the buffer to move (if such a thing is possible, I wasn't able to find the
buffering logic in the libc code) also needs to read some data to avoid
uninitialized holes in the buffer which would prevent writing it back to the
file in a single chunk.

You could push the idea to the extreme and have a single 'validity' bit for each
byte in the buffer and act optimally according to those. That would be overkill
as the idea above would handle most interesting cases with far less overhead and
risk of bugs.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=5742

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.


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