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

Re: at least 260 packages broken on arm, powerpc and s390 due to wrong assumption on char signedness

On Mon, Dec 31, 2001 at 01:33:37PM -0500, Colin Walters wrote:
> On Mon, 2001-12-31 at 05:40, Julian Gilbey wrote:
> > I believe that the author (Knuth) presumably thought "c should only be
> > between 0 and 127, probably not even that far, and we're using c as an
> > array index, where we've only allocated 256 chars for this array.  
> Right.  Then it should be explicitly declared as an "unsigned char".
> > As char might be a signed char, c could feasibly be less than 0, 
> Not if you declare it as unsigned explicitly.
> > and there's a small possibility that char could be some weird wide
> > character thing, 
> No, the C standard guarantees that a char is exactly a single byte; i.e.
> sizeof(char) == 1.
> > so c could feasibly be greater than 255, we'll
> > perform the checks just check to be on the safe side."  Defensive
> > programming.
> It can't be larger than 255 (precisely because it is limited to a single
> byte).
> The more I think about it, the more it makes sense to always explicitly
> declare all char variables as signed or unsigned; otherwise, you're just
> asking for latent bugs.

As someone pointed out, a byte is required to contain at least the
unsigned 0 - 255 range.  It can be larger.  A lot of DSP chips support
32-bit access as the basic element.  sizeof(char) == sizeof(long) == 1.

Or he could have char redefined in a really stupid and non-C-conforming
header somewhere someday.  Not his fault.

Characters intended to contain character data should in fact be 'char'
rather tahn explicitly signed.  The C library expects them that way;
and the default is chosen for increased performance on the architecture
in question, generally, or compatibility.

Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Reply to: