On Wed, Jan 23, 2013 at 6:51 PM, Thomas Preud'homme
<address@hidden> wrote:
Le jeudi 24 janvier 2013 00:45:34, Thomas Preud'homme a écrit :
> No need to do any of what I asked. The error is in the test itself:
>
> As you said, the test runs as follows:
>
> char inChar;
>
> while ((inChar = fgetc(f)) != EOF)
> //do something
>
> The problem stems from the fact that fgetc returns an int, not a char. This
> is for a very good reason: EOF is defined to (-1). Characters can be
> either signed or unsigned (the C standard leaves this choice up to the
> compiler if I remember well) and it seems tcc and gcc consider char as
> being unsigned. Thus, when the return value from fgetc is stored in
> inChar, it changes from -1 to 255. Then, to do the comparison between
> inChar and EOF, the compiler will cast inChar in int because int is bigger
> than char. So you'll compare 255 to -1. If the int were to be casted down
> to char, then it'll work (as in comparing to (char) EOF).
As to why is arm the only platform affected:
% egrep -RIn CHAR_IS_UNSIGNED *
arm-gen.c:134:#define CHAR_IS_UNSIGNED
libtcc.c:1019:#ifdef CHAR_IS_UNSIGNED
It's the only architecture using unsigned char :)
Tom