Re: fwrite.c bugfix

[Remco Treffkorn <remco@rvt.com>]

On Saturday 12 July 2003 14:22, Ethan Benson wrote:
> On Sat, Jul 12, 2003 at 12:23:26PM -0700, Remco Treffkorn wrote:
> > > no your patch is broken.  on error it returns number of items written,
> > > NOT number of short items as the documentation states:
> > >
> > > If an error occurs, or the end-of-file is reached, the return value is
> > > a short item count (or zero).
> > > ^^^^^^^^^^^^^^^^^^
> >
> > Here comes that language thing again. When I read the man page, I
> > interpret this as 'a number short of the requested number', which is
> > consistent with 'returns the number of items written'. Why we would turn
> > around and make this 'the number of items yet to be written' is beyond
> > me.
>
> i interpret it as the latter, but your right this is vague and subject
> to interpretation, either we need to find another place this is
> documented (C standards) or else test glibc or some other established
> implementation to see what it does.
>

Ok, I checked the sysV man page:
     DIAGNOSTICS
          Fread and fwrite return the number of items read or written.
          If size or nitems is non-positive, no characters are read or
          written and 0 is returned by both fread and fwrite.

I then had the source for sysV fwrite.c checked. It in deed returns the number 
of items actually written, not the ones remaining to be written.

> > The wording in the linux man page is poor. I checked diet libc (source
> > code), and it chooses to implement the return of zero in the error case.
> > So, no help
>
> the man page says zero is an acceptable return value.

Since that means you can not portably rely on the return value (because zero 
is allowed), let's just do zero and be done with it.

-- 
Remco Treffkorn (RT445)
HAM DC2XT
remco@rvt.com   (831) 685-1201