Re: Sub-optimal libc's read-ahead buffering behaviour

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?

	David.