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)?

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

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.

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