fwrite inconsistency

[Chris Faylor]

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