[Bug stdio/13975] fopencookie interface surprising

["ray at bellis dot me.uk" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=13975

Ray Bellis <ray at bellis dot me.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ray at bellis dot me.uk

--- Comment #1 from Ray Bellis <ray at bellis dot me.uk> ---
I've just been bitten by this.

The "private" header file libio.h has this to say:

"Write N bytes pointed to by BUF to COOKIE.  Write all N bytes
 unless there is an error.  Return number of bytes written.  If
 there is an error, return 0 and do not write anything."

However the man page for fopencookie(3) makes no mention of the fact that a
short write isn't possible.  It even implies (to my reading at least) that a
short write *is* possible:

"As its function result, the write function should return
 the number of bytes copied from  buf, or 0 on error."

FWIW, in my tests this does appear contrary to the equivalent funopen(3) in
BSD, which given a short write will call the writer function repeatedly until
all of the data is consumed.  Unlike glibc, in BSD's libc it appears that all
stdio is dispatched via funopen semantics, so it pretty much *has* to be able
to support short writes.

Personally, I think glibc should adopt the funopen behaviour.  AFAICS, any
fopencookie code that already works if the writer outputs the whole buffer
would continue to work perfectly.

I've attached a program that shows the difference in behaviour between Linux
and OSX.  Note that on OSX (and probably other BSDs) the first call to `fwrite`
appears to go direct to the writer function without buffering, whereas in glibc
a call to the writer doesn't occur until the first buffer flush (or close).

-- 
You are receiving this mail because:
You are on the CC list for the bug.