Your code seems to work, because the implicit type conversions accidentally happen to do the right thing.
getchar() returns an
int with a value that either fits the range of
unsigned char or is
EOF (which must be negative, usually it is -1). Note that
EOF itself is not a character, but a signal that there are no more characters available.
When storing the result from
c, there are two possibilities. Either the type
char can represent the value, in which case that is the value of
c. Or the type
char can not represent the value. In that case, it is not defined what will happen. Intel processors just chop off the high bits that don't fit in the new type (effectively reducing the value modulo 256 for
char), but you should not rely on that.
The next step is to compare
EOF is an
c will be converted to an
int as well, preserving the value stored in
c could store the value of
EOF, then the comparison will succeed, but if
c could not store the value, then the comparison will fail, because there has been an irrecoverable loss of information while converting
EOF to type
It seems your compiler chose to make the
char type signed and the value of
EOF small enough to fit in
char were unsigned (or if you had used
unsigned char), your test would have failed, because
unsigned char can't hold the value of
Also note that there is a second problem with your code. As
EOF is not a character itself, but you force it into a
char type, there is very likely a character out there that gets misinterpreted as being
EOF and for half the possible characters it is undefined if they will be processed correctly.