On Sat, Aug 06, 2005 at 02:08:58PM +1200, Dave Sainty wrote:
> Joerg Sonnenberger writes:
> 
> > >    The optional bufsize argument specifies the file's desired buffer
> > >    size: 0 means unbuffered, 1 means line buffered, any other positive
> > >    value means use a buffer of (approximately) that size. A negative
> > >    bufsize means to use the system default, which is usually line
> > >    buffered for tty devices and fully buffered for other files. If
> > >    omitted, the system default is used.
> > 
> > Ah! I've seen this problem on DragonFly too. Now it makes perfect sense.
> > Turning off buffering means a few things in the BSD libc:
> > (a) Reads are done with a buffer size of 1. That might arguable be a bug
> > for fread() or not, it's hard to say. I'm investigating.
> > (b) All open FILEs are fflushed before reading from such a file.
> > (c) Certain IO routines are checking for '\n' and handling it specially.
> 
> I'd guess that the reason for (a) is to support (c)?

That's one reason. The other is simply that doing reads of 1 byte each
are the simplest way to use the same algorithm for buffered and
not-buffered operation :-)

> But if that's the case, it probably is an inefficiency to break
> block-fread()'s down into single-byte reads.

Yes, I think so.

> Perhaps it would be better to train fread() to read directly into the
> passed buffer, rather than repeatedly call __srefill() and copy the
> buffer - which in the unbuffered case is a 1-byte buffer.

That was exactly my thought. The question is how the various stdio
routines interact.

> Though one has to wonder what the justification for using stdio for
> purely unbuffered access is...  Maybe it's a Python programmer thing
> :)

The Python file object is using stdio by default. That's fine as long as
you do what every normal program does -- namely using buffered IO.

Joerg