[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

potential runtime problem on arm, powerpc and s390 due to incorrect assumption on char signedness

Hash: SHA1

as already discussed on debian-devel, I would like to draw your attention 
to a potential runtime problem for each package on arm, powerpc and s390.

As I experienced, a lot of people assume that char is signed per default. 
This is _not_ true on arm, powerpc and s390.

The following explanation of a typical problem can be found at

>>The following code fragment will ignore the end-of-file when char is 
>>implemented using unsigned char, due to internal conversions between data
>>                char c;
>>                while ((c = getchar()) != EOF)
>>                      process character in c
>>EOF is usually -1.  When getchar() returns a -1, that value immediately goes
>>into an instance of type plain char, c.  If plain char is not signed, then 
>>an internal conversion copies the low-order bits of -1 into c; now c is 255.
>>Moreover, EOF, which is signed, finds itself to be the right hand operand 
>>in a mixed-mode expression involving an unsigned operand.  In this case, 
>>the signed value is raised to an unsigned value; -1 now becomes 65,535.  
>>Finally, 255 is never equal to 65,535; the relational test is always true; 
>>and the EOF is ignored.  The correction is to make the type of variable c 

In other contexts the right solution is to make the type of the variable 
'signed char'.

In most cases the compiler will issue one of the following warnings:

comparison is always true due to limited range of data type
comparison is always false due to limited range of data type
comparison of unsigned expression >= 0 is always true
initialization of negative value \`-1' to \`char'
pointer targets in assignment differ in signedness
pointer targets in passing arg 1 of \`...' differ in signedness

Please check the build log of your package on one of the platforms mentioned 
above for the warnings.

A not complete list of packages that have got this problem ordered by package 
owner can be found at


The build logs of these packages are at http://buildd.debian.org or at
http://people.debian.org/~gt/ .

Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org


Reply to: