Up to now, i have found out that, we use getchar() as int because at EOF this function returns -1. I was wondering can't char hold -1 ? i think it can,because it can also range from -128 to 127.
I searched through the top list of google, but the answer i got didn't satisfy me.
First of all, just to clear something up,
EOF is not required to be specifically -1. The ISO C standard requires it to have a negative value.
Also note that the type
char can be signed or unsigned; that is implementation-defined.
getchar can be used to process binary streams, not only text streams. Bytes have values from 0 to
UCHAR_MAX. The natural type for this range is
unsigned char. The return value of
getc couldn't be
unsigned char, because
EOF wouldn't be representable. It couldn't be
signed char either, because
signed char cannot hold the values from 0 to
UCHAR_MAX. So, a wider type is chosen: the type
int. On mainstream platforms,
int is wider than
char: it has a size of at least 2. And so it it is capable of representing some negative value that can be used for
EOF, and all the byte values in the range 0 to
In some C implementations (for systems such as some DSP chips) this is not true:
int is one byte wide. That represents challenges. On such a C implementation, a range of valid byte values returned by
getc just has to be negative, and one of those values clashes with
EOF. Carefully written code can tell that this is the case: a value equal to
EOF was returned, yet the
ferror functions report false: the stream is not in error, and end-of-file has not occurred. Thus, the value which looks like
EOF is actually a valid byte.