0

I have the following code:

FILE *f = fopen('/path/to/some/file', 'rb');
char c;
while((c = fgetc(f)) != EOF)
{
    printf("next char: '%c', '%d'", c, c);
}

For some reason, when printing out the characters, at the end of the file, an un-renderable character gets printed out, along with the ASCII ordinal -1. 

next char: '?', '-1'

What character is this supposed to be? I know it's not EOF because there's a check for that, and quickly after the character is printed, the program SEGFAULT.

Natan Streppel
  • 5,759
  • 6
  • 35
  • 43
  • FYI: You should make sure that `fopen` doesn't return NULL, indicating failure. – Jonathon Reinhart Apr 28 '14 at 02:44
  • This could be closed as a duplicate of either [`while ((c = getc(file)) != EOF)` loop won't stop executing](http://stackoverflow.com/questions/13694394/) or [C programming - K&R example 1.5.2 - modified program not functioning as intended](http://stackoverflow.com/questions/12116864/) or a dozen other similar answers I've made, not to mention those made by others on the same topic. – Jonathan Leffler Apr 28 '14 at 03:15

2 Answers2

7

The trouble is that fgetc() and its relatives return an int, not a char:

If the end-of-file indicator for the input stream pointed to by stream is not set and a next character is present, the fgetc function obtains that character as an unsigned char converted to an int and advances the associated file position indicator for the stream (if defined).

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.

It has to return every possible valid character value and a distinct value, EOF (which is negative, and usually but not necessarily -1).

When you read the value into a char instead of an int, one of two undesirable things happens:

  • If plain char is unsigned, then you never get a value equal to EOF, so the loop never terminates.

  • If plain char is signed, then you can mistake a legitimate character, 0xFF (often ÿ, y-umlaut, U+00FF, LATIN SMALL LETTER Y WITH DIAERESIS) is treated the same as EOF, so you detect EOF prematurely.

Either way, it is not good.

The Fix

The fix is to use int c; instead of char c;.

Incidentally, the fopen() call should not compile:

FILE *f = fopen('/path/to/some/file', 'rb');

should be:

FILE *f = fopen("/path/to/some/file", "rb");

Always check the result of fopen(); of all the I/O functions, it is more prone to failure than almost any other (not through its own fault, but because the user or programmer makes a mistake with the file name).

Jonathan Leffler
  • 730,956
  • 141
  • 904
  • 1,278
  • Upon successful completion fopen() returns a FILE pointer. Otherwise, NULL is returned and errno is set to indicate the error. Use the following for error checking in fopen : if((fp=fopen("mat", "rb"))==NULL) { printf("Cannot open file.\n"); return 0; } – Mayank Apr 29 '14 at 10:43
3

This is the culprit:

char c;

Please change it to:

int c;

The return type of fgetc is int, not char. You get strange behavior when you convert int to char in some platforms.

R Sahu
  • 204,454
  • 14
  • 159
  • 270
  • I presume what is happening is that since `char` is sometimes unsigned, unlike other data types, -1 (a common `EOF` value) is implicitly cast to 255. When then again cast to `int` to compare to `EOF`, it stays 255, and thus doesn't equal -1. – Gort the Robot Apr 28 '14 at 02:47