>> Given that the interface exists and has a particular meaning
>> already, I'd follow that.
> FWIW, I agree with this, although the manual should be explicit that
> it doesn't match what you might expect if you're familiar with the
> semantics of FIONREAD.

The problem is, FIONREAD's semantics can be described in multiple
very similar different ways, which despite being very similar lead to
very different semantics for FIONWRITE.

> 	FIONREAD int
> 		Get the number of bytes that are immediately available
> 		for reading.

> 	FIONWRITE int
> 		Get the number of bytes that are immediately available
> 		for writing.

Right.  But if, instead, you phrase FIONREAD as

	FIONREAD int
		Get the number of bytes the kernel is currently
		buffering for read.

then FIONWRITE becomes

	FIONWRITE int
		Get the number of bytes the kernel is currently
		buffering for write.

which is basically the version that started this thread off.

That actually isn't how FIONREAD is defined, as its behaviour on plain
files makes clear, but it amounts to the same thing for practically
everything else.  It's the way I thought of it until this discussion,
and it's probably the way a lot of other people thought of it too.

The names are wrong for those semantics, though; something like
FIONRQSIZE and FIONWQSIZE would be better.  But I suppose that's water
under the bridge by now.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B