Subject: Re: archive.c/arm32
To: John F. Woods <firstname.lastname@example.org>
From: Chris G. Demetriou <email@example.com>
Date: 03/23/1998 18:19:36
> > > > ((int)val & 0x100) == 0
> > > > (if 'val' is signed and negative, it'll be sign-extended, so bits
> > > > above the low 8 will be set. otherwise those bits will be zero.)
> > > If we were willing to require ANSI C,
> > > (signed char)val >= 0
> > No it wouldn't, because that would _force_ all chars to be signed,
> > even if the implementation's chars are by default unsigned.
> Doh! I misunderstood the intent of the original expression.
> In that case, I think that
> (int)val >= 0
> does the right thing in every useful case: if val is an unsigned type
> strictly narrower than int, the result of casting to int will still be a
> positive small integer; if val is a signed type strictly narrower than
> int, then (int)val is negative if and only if val is negative. Plus, it
> doesn't misfire if char is wider than 8 bits (as if the code wrapped around
> that line wouldn't!), and it more directly expresses the intent.
However, the original goal was to come up with an expression which
yields the correct result _and_ which avoids the gcc "comparison is
always 1 due to limited range of data type" warning.
(val >= 0) yields the correct result, but causes that warning.
((int)val >= 0) yields the correct result, but also causes that
(((int)val & 0x100) == 0) also yields the correct result (for machines
where char is 8 bits -- i.e. all machines that NetBSD supports), but
does not cause that warning. The expression is still always true on
unsigned-char machines, but gcc isn't sophisticated enough to catch
I'd love to hear a better suggestion, but... 8-)