Warning request.

Gabriel Paubert paubert@iram.es
Sun Feb 27 01:02:00 GMT 2000

On Sat, 26 Feb 2000, Kevin Atkinson wrote:

> I just ran into a problem with my aspell package
> ( http://aspell.sourceforge.net ) on linux on the powerpc which relates
> the the following code:
>     char c;
>     while ((c = FILE.get()) != EOF) ...
> Which on the powerpc will give the warning:
> aspell.cc:611: warning: comparison is always true due to limited range
> of data type
> However on platforms with a signed character no warning is given -- even
> with -Wall.

And will fail silently the day you spell check a file in a language which
use character code 255, which is `latin lowercase y with diaeresis' in
ISO-8859-1 and its replacement ISO-8859-15. Admittedly not a frequent
letter but it is used in some french (and belgian IIRC) nouns at least
(and probably other languages which I don't happen to know).

[Actually ISO-8859-1, contrary to the claims, did not support french,
since it missed a ligature used in some very common words but don't get me
started on that.]

Obviously what is wrong with this code is putting the return value of get
into a char. At least standard fgetc is defined to return an unsigned char
cast to an int or EOF, so that you can't confuse data with metadata.
Hopefully your FILE.get is defined in the same way.

> Is there some way for egcs to warn about comparison of a "char" to a
> negative integer constant on platforms with a signed char?  

What about using -funsigned-char for tests, and using testcases which
include character \0xff ? 

I think you have all the tools, and this warning would actually be
triggered on perfectly valid code (comparing the readout of an 8 bit
bipolar ADC with fixed threshholds).

Then remove the option for production on the platforms on which it
improves the code. I don't know of any arch on which using signed char
leads to shorter or faster code; this does not mean that they don't exist,

> It would be really help full as the submitted of the bug report claimed
> code like this is 
> responsible for 50 % of porting problems to the PowerPC.

And actually the original code is buggy, it just does not show often...

More information about the Gcc mailing list