Bug 8446 - fwrite(buf, 0, 1, fp) returns 1, SUS says should return 0
fwrite(buf, 0, 1, fp) returns 1, SUS says should return 0
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: glibc (Show other bugs)
6.1
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-01-13 11:08 EST by Jay Turner
Modified: 2016-11-24 07:27 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-05-22 10:52:03 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Glen Foster 2000-01-13 11:08:36 EST
VSX-PCTS has found a SUS-conformance defect in our implementation of the
fwrite() interface.  According to the SUS:

======================================================================
RETURN VALUE

	The fwrite() function returns the number of members successfully
	written, which may 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.
======================================================================

Yet when the following test program is run, the combination of:
	(a) element size of 0
	(b) element count of 1

yields fwrite() returning 1 -- SUS says above it should return 0 (when
*either* size or nitems is 0).

[snip]
#include <stdio.h>
#include <string.h>

#define FILENAME        "./testfile"
#define STRDATA         "This is a test\n"

main()
{
        FILE *fp;
        int val, len = strlen(STRDATA);

        if ((fp = fopen(FILENAME, "w")) == (FILE *) NULL) {
                perror(FILENAME);
                exit(1);
        }
        printf("fopen(\"%s\", \"w\") returns successfully\n", FILENAME);

        if ((val = fwrite(STRDATA, len, 1, fp)) != 1) {
                perror("fwrite(size != 0, count != 0)");
                fprintf(stderr, "fwrite() returned %d, expected 1\n", val);
                exit(1);
        }
        printf("fwrite(): [size != 0, count != 0] returns %d (success)\n",
		val);
        if ((val = fwrite(STRDATA, len, 0, fp)) != 0) {
                perror("fwrite(size != 0, count == 0)");
                fprintf(stderr, "fwrite() returned %d, expected 0\n", val);
                exit(1);
        }
        printf("fwrite(): [size != 0, count == 0] returns %d (success)\n",
		val);
        if ((val = fwrite(STRDATA, 0, 1, fp)) != 0) {
                perror("fwrite(size == 0, count != 0)");
                fprintf(stderr, "fwrite() returned %d, expected 0\n", val);
                exit(1);
        }
        printf("fwrite(): [size == 0, count != 0] returns %d (success)\n",
		val);
        (void) fclose(fp);
        exit(0);
}
Comment 1 Cristian Gafton 2000-01-13 11:31:59 EST
This is really a very deliberate thing so that glibc will conform to the
ANSI/ISO C9X standards

It is an intentional non-compliance
Comment 2 Cristian Gafton 2000-05-22 10:52:59 EDT
assign to jakub
Comment 3 Jakub Jelinek 2000-09-08 04:06:19 EDT
Actually, this returns 0 in glibc 2.1.9x, probably the contradicting
standards were adjusted to match SUS.

Note You need to log in before you can comment on or make changes to this bug.