My question is, how does he know it fails for, "no good reason." He said
GetLastError() returns 0. I don't see the MSVC++ documentation mentioning
that fwrite() will ever call SetLastError(). So the fact that it returns 0
does not mean no error occurred, it just means that that value is not set by
this function. I went and looked through the MSVCRT source code (fwrite.c)
and indeed, nothing calls SetLastError(), nor, for that matter, errno.
Instead, it sets the stream's error code. To determine what error occurred,
you need to use ferror() on the stream, not GetLastError(). My guess is that
ferror() will not return 0.

I think if we know exactly what the error is, we have a better chance of
finding out what caused it.

Dominick Meglio

----- Original Message -----
From: "Daniel Stenberg" <daniel-curl_at_haxx.se>
To: <curl-library_at_cool.haxx.se>
Sent: Wednesday, July 28, 2004 5:23 PM
Subject: RE: curl bug #994165 (fwd)

> Hi friends
>
> I've been mailing back and forth with Orna Haber, who filed bug report
> #994165:
>
http://sourceforge.net/tracker/index.php?func=detail&aid=994165&group_id=976&atid=100976
>
> He has attached source files that both show how to repeat the problem as
well
> as his suggested fix for it.
>
> Since this is on Windows, I need input from people with Windows knowledge.
>
> It is apparently a case where fwrite() returns an error, but if the
fwrite()
> is retried, it succeeds!
>
> Is this a bug in Windows' fwrite()-implementation we need to work-around?
>
> (The mail below is forwarded with permission.)
>
> --
> Daniel Stenberg -- http://curl.haxx.se -- http://daniel.haxx.se
> Dedicated custom curl help for hire: http://haxx.se/curl.html
>
> ---------- Forwarded message ----------
> Date: Wed, 28 Jul 2004 15:31:36 -0400
> From: "Haber, Orna"
> Subject: RE: curl bug #994165
>
> 1. You wrote:
> " Yes I know and that's why I asked you. How can this happen?"
>
> >> I sent you a source files that describe test steps to reproduce the
> failure if you really want to study HOW CAN THIS HAPPEN as I don't know
> the answer to this question.
> What I do know is that despite the failure to write, if I try to write
> the remaining buffer to Http server, on the second write, it will
> succeed and the file that I am trying to write will not be corrupt which
> means that my wish for today has just been fulfilled...
>
> " The fwrite() function returns the number of members successfully
> written,
> which may be less than nitems if a write error is encountered.
>
> ... so, if it is less than the number passed in, it is a failure."
>
> My reply>> That's right, libcurl returns a Write-error due to 'wrote' <
> 'len' BUT because there is no good reason for failure, I made a retry
> for the remaining buffer. Good reasons for failure could be any of the
> following:
> 1. The channel of communication dropped dead and couldn't be
> re-established. (No, this is not the case)
> 2. Insufficient disk-space (No, this is not the problem)
>
> 2. You wrote: " That is an ugly work-around that shouldn't be necessary
> and again: that's why
> I asked you how you can make fwrite() return a bad value."
>
> Your conclusion: " Until you can convince me that this behavior is
> normal and expected on
> Windows, I won't do anything about it but only consider it a peculiar
> Windows
> bug. The code uses fwrite() as fwrite() is documented to work.
>
> Please take this discussion to the libcurl mailing list with further
> details
> if you still disagree with me. I don't know much about Windows or
> Windows
> internals."
>
> My reply>> This behavior is not normal and it could be that someone who
> is expert in Windows internals might have a look at this bug before you
> throw it to the dust-bin and this expert might come up with a much
> better solution than the patch that I wrote in sendf.c. I would like to
> suggest that you forward this bug description to a Windows expert as I
> do not intend to pursue justice by taking it further to libcurl mailing
> list.
> I will be happy to co-operate with a Windows expert (or anyone) who
> starts studying the test source files that I sent and needs further
> assistance at reproducing the bug in order to solve it better than the
> ugly path that I wrote.
> Despite disagreeing with you I would like to thank you for your mail.
> It indicates that you were interested in looking into this problem.
> Orna Haber
>
>
> -----Original Message-----
> From: Daniel Stenberg [mailto:daniel_at_haxx.se]
> Sent: Wednesday, July 28, 2004 11:53 AM
> To: Haber, Orna
> Subject: RE: curl bug #994165
>
> On Mon, 26 Jul 2004, Haber, Orna wrote:
>
> > 2. fwrite() should never return anything by the same amount as given
> to it,
> > as everything else is a failure. Can you explain why fwrite() fails
> for you
> > in this case
> >
> > As the title of the bug suggests: I don't see a good reason for
> fwrite() to
> > return 'wrote' < 'len' and fail.
>
> Yes I know and that's why I asked you. How can this happen?
>
> (quote from the Single UNIX (r) Specification, Version 2 for fwrite:)
>
> RETURN VALUE
>
> The fwrite() function returns the number of members successfully
> written,
> which may be less than nitems if a write error is encountered.
>
> ... so, if it is less than the number passed in, it is a failure.
>
> > In the bug, I attached a zip file that includes sendf.c with a
> proposed
> > solution (patch): All the patch does it to fwrite() the remaining
> bytes to
> > the server, which makes sure that the complete buffer is written
> > successfully.
>
> That is an ugly work-around that shouldn't be necessary and again:
> that's why
> I asked you how you can make fwrite() return a bad value.
>
> > Please note that it always fails on writing a header (type of) info to
> the
> > server and it happens on the 9th file written to the server.
>
> Until you can convince me that this behavior is normal and expected on
> Windows, I won't do anything about it but only consider it a peculiar
> Windows
> bug. The code uses fwrite() as fwrite() is documented to work.
>
> Please take this discussion to the libcurl mailing list with further
> details
> if you still disagree with me. I don't know much about Windows or
> Windows
> internals.
>
> --
> -=- Daniel Stenberg -=- http://daniel.haxx.se -=-
> ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol
>
>
>
Received on 2004-07-28