fwrite inconsistency
Chris Faylor
cgf@cygnus.com
Fri Aug 11 19:48:00 GMT 2000
On Fri, Aug 11, 2000 at 07:42:58PM -0700, J. J. Farrell wrote:
>> From: "Jimen.Ching" <JChing@adtech-inc.com>
>>
>> The problem below produces "0 0" as output on HPUX and Solaris 2.5 with gcc
>> 2.8.x. But using gcc 2.95.x on cygwin, I get "0 1". I also tried using
>> Borland BCC, and I also got "0 1". Is GCC trying to behave like MS
>> compilers under cygwin?
>>
>> Is it correct for size2 to contain 1? What does ANSI/ISO say about this?
>>
>> -----------------------------------------------------
>> #include <stdio.h>
>>
>> int
>> main(int argc, char *argv[])
>> {
>> int size1, size2;
>> FILE *fp;
>>
>> fp = fopen("tst.log", "w");
>> size1 = fwrite(0, 1, 0, fp);
>> size2 = fwrite(0, 0, 1, fp);
>> printf("%d %d\n", size1, size2);
>>
>> return 0;
>> }
>
>Standard C says that your program produces undefined behaviour
>because of the first parameter you give to the fwrite() calls.
>The rest of this discussion assumes that your program gives the
>same results with a valid first parameter.
>
>Standard C doesn't comment on the effect of giving 0 for "size"
>or "nmemb". It's clear from the definition that the first case
>should always return 0. The value returned in the second case
>depends on the implementor's view of whether or not a zero-length
>write succeeds.
>
>XPG3 and the Standard Unix Specification explicitly say
>
> If size or nitems is 0, fwrite() returns 0
>
>I haven't checked, but it's very likely that POSIX says the same.
>
>This looks like a bug in cygwin's fwrite().
Cygwin uses newlib's fwrite. If you send this bug report to
newlib@sources.redhat.com you'll probably have better luck getting
it fixed.
cgf
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com
More information about the Cygwin
mailing list