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: