[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: fwrite.c bugfix
Ethan,
English is not my primary language. I came to it rather late. This is why I
tend to be very pedantic in trying to understand what people mean. Many
things that you would pick up at a glance, I have to consciously parse and
decode. If I am not able to make sense out of what I see, I tend to ask. I am
still used to just not getting it and want to give people a chance to
explain.
On Saturday 12 July 2003 01:41, Ethan Benson wrote:
> On Fri, Jul 11, 2003 at 12:41:55PM -0700, Remco Treffkorn wrote:
> > On Friday 11 July 2003 01:59, Ethan Benson wrote:
> > > On Thu, Jul 10, 2003 at 05:35:33PM -0700, Remco Treffkorn wrote:
> > > > Fwrite is supposed to return the number of items written.
> > >
> > > number of items, NOT number of characters:
> >
> > I write: "Fwrite is supposed to return the number of items written", you
> > write "number of items, NOT number of characters". You are re-stating
> > what I said. Am I missing the point?
>
> no but your patch changed it to return number of items written, not
> number of shorted items (on errors) as the docs seem to say should happen.
I make a statement, you repeat it with an added emphasis on what I did NOT
say. I think: why would he do that? What am I missing?
You answer in a way. Your answer contains a new statement, that has nothing to
do with the original question. You claim "not number of shorted items (on
errors) as the docs seem to say should happen". You do not explain why you
said "NOT number of characters".
>
> > It does not 'appear' to be broken, it is broken.
>
> dont be an ass.
>
Too much to ask.
When you say 'appears' that tells me you are not convinced. This is why I
explain it again, and claim it IS broken. If you are still not convinced that
it is broken, please tell me what I need to do to convince you.
> > The return value should be the number of items successfully written.
> > There is no anbiguity here. Please re-consider, the patch appears to fix
> > it properly.
>
> 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.
>
...
...
> > This fixes the trivial, non-error case. The name 'nwrote' better reflects
> > purpose. The return value in the error case is still wrong. For the 'two
> > item case failing on the second' case you still return -1 instead of 1.
> > You need to return 'nwrote', not 'count-nwrote'.
> >
> > Do you want me to re-submit a patch against todays version, or is the
> > original from yesterday still usefull?
>
> your patch is wrong. it returns number of SUCESSFUL writes, not the
> number of SHORTED writes.
>
> you may submit a new patch, which actually implements documented behavior.
Remember? You fixed it. Why would I have to submit a patch to fix something
you did already? Because you pretty cavalierly skip over the fact that your
fix is broken. Why do I take the time to demonstrate it, when you don't even
acknowledge it? What am I to think? You did not even read it, and I wasted my
time, or you did and don't want to admit it?
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
here. I checked the source for a proprietary clib, one that I respect above
others, and it implements what the following excerpts describe.
http://bama.ua.edu/cgi-bin/man-cgi?fwrite+3C:
The fwrite() function returns the number of elements suc-
cessfully written, which might be less than nitems if a
write error is encountered. If size or nitems is 0, fwrite()
returns 0 and the state of the stream remains unchanged.
Otherwise, if a write error occurs, the error indicator for
the stream is set and errno is set to indicate the error.
http://www.rocketaware.com/man/man3/fread.3.htm:
The function fread() does not distinguish between end-of-file and error,
and callers must use feof(3) and ferror(3) to determine which occurred.
The function fwrite() returns a value less than nmemb only if a write er-
ror has occurred.
Nowhere did I find anything supporting your interpretation of the unfortunate
wording in the man page.
--
Remco Treffkorn (RT445)
HAM DC2XT
remco@rvt.com (831) 685-1201