Sub-optimal libc's read-ahead buffering behaviour
dwmalone at maths.tcd.ie
Thu Aug 4 09:26:41 GMT 2005
On Thu, Aug 04, 2005 at 05:57:11PM +1000, Peter Jeremy wrote:
> That said, I've seen similar behaviour on other systems so it could be
> a subtle side-effect of POSIX.
There are some magic things about fseek in the C standard - I wonder
if this could be related to them. For example (from C99) in the
commentry on fopen:
When a file is opened with update mode ('+' as the second
or third character in the above list of mode argument
values), both input and output may be performed on the
associated stream. However, output shall not be directly
followed by input without an intervening call to the fflush
function or to a file positioning function (fseek, fsetpos,
or rewind), and input shall not be directly followed by
output without an intervening call to a file positioning
function, unless the input operation encounters endof- file.
Opening (or creating) a text file with update mode may
instead open (or create) a binary stream in some implementations.
and in ungetc:
The ungetc function pushes the character specified by c
(converted to an unsigned char) back onto the input stream
pointed to by stream. Pushed-back characters will be returned
by subsequent reads on that stream in the reverse order of
their pushing. A successful intervening call (with the
stream pointed to by stream) to a file positioning function
(fseek, fsetpos, or rewind) discards any pushed-back
characters for the stream. The external storage corresponding
to the stream is unchanged.
and in fseek:
After determining the new position, a successful call to
the fseek function undoes any effects of the ungetc function
on the stream, clears the end-of-file indicator for the
stream, and then establishes the new position. After a
successful fseek call, the next operation on an update
stream may be either input or output.
Could what stdio is doing be related to flushing ungetc?
More information about the freebsd-current