This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

fgetc non-conformance with C99 -- bug or conscious decision?


Hello,

What is the "official" glibc position regarding the change in behavior
of the stdio input functions with respect to EOF, as described in the
comment header of the attached example app illustrating non-conformance
with C99?

Manuel
/* Illustrate C99 non-compliance regarding end-of-file flags and stdio input.

  The specified behavior of the stdio input functions has changed since C89.

  In the ANSI/ISO C99 standard, the description of fgetc() states in item 3
  (relavent change from C89 behavior in uppercase)

    IF THE END-OF-FILE INDICATOR FOR THE STREAM IS SET, or if the stream is at
    end-of-file, the end-of-file indicator for the stream is set and the FGETC
    FUNCTION RETURNS EOF. Otherwise, the fgetc function returns the next character
    from the input stream pointed to by stream.  If a read error occurs, the error
    indicator for the stream is set and the fgetc function returns EOF.

  The Single Unix Specification Version 3 agrees with the ANSI/ISO C99 (as ususal).

  This of course affects other stdio input functions defined in terms of fgetc();

  The meaning of a stream's end-of-file indicator was (apparently) originally
  questioned in Defect Report #141,
    http://wwwold.dkuug.dk/JTC1/SC22/WG14/www/docs/dr_141.html
  with the response:
  
    It was certainly the intent of the Committee that end-of-file should indicate
    ``no more input from a stream,'' at least when returned by functions such as
    fgetc. In particular, subclause 7.9.7.1 The fgetc function says, in part:
      If the stream is at end-of-file, the end-of-file indicator for the stream is
      set and fgetc returns EOF. ``Setting the end-of-file indicator'' implies that
      that stream is now considered to be ``at end-of-file.''
    For input from a stream to return other than EOF after once returning EOF
    (with no intervening file-positioning operations or calls to clearerr) is
    non-conforming behavior, however widespread. 
  
*/

#include <stdio.h>
#include <stdlib.h>

static const char filename[] = "test-read-after-eof.txt";

int main(void)
{
	FILE *fr;
	FILE *fo;
	int i, c, e;
	int retval = EXIT_SUCCESS;

	if (!(fo = fopen(filename, "w"))) {
		fprintf(stderr, "fopen(w) failed\n");
		return EXIT_FAILURE;
	}

	if (!(fr = fopen(filename, "r"))) {
		fprintf(stderr, "fopen(r) failed\n");
		return EXIT_FAILURE;
	}

	e = 0;
	for (i = 0 ; i < 3 ; i++) {
		e = feof(fr);
		printf("pass %d : feof(fr)=%d", i, e);
		c = fgetc(fr);
		if (e && (c != EOF)) {
			printf("  C99 violation -- feof() was true but fget() returned '%c'", c);
			retval = EXIT_FAILURE;
		}
		if (i == 1) {
			printf("  appending 'X' to test file");
			if (fprintf(fo, "X") == 0) {
				fprintf(stderr, "fprintf failed\n");
				return EXIT_FAILURE;
			}
			if (fflush(fo)) {
				fprintf(stderr, "fflush failed\n");
				return EXIT_FAILURE;
			}
		}
		printf("\n");
	}

	printf("done\n");

	fclose(fo);
	fclose(fr);
	remove(filename);

	return retval;
}

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]