Of course, I should have seen that! I looked right at it.... Like many programmers, I have grown lazy about many compiler warnings, and signed vs. unsigned conversions/promotions is one I often ignore. In this case the issue, with or without warning, is serious. Good catch.
Thanks, Jerry On Wed, Jan 23, 2013 at 6:51 PM, Thomas Preud'homme <[email protected]>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 > -- Interested in bats? Check out my blog at: http://www.karaokebats.com/
_______________________________________________ Tinycc-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/tinycc-devel
