Mail Archives: djgpp-workers/1999/06/14/11:35:36
On Mon, 14 Jun 1999, Eli Zaretskii wrote:
> > The rule is simple: a char that is to be passed to a <ctype.h> functions
> > must either already *be* a unsigned char, or be casted into one.
>
> Where is this rule spelled out?
Nowhere, at least not in such strong terms. But the matter still holds: A
variable of type 'signed char' (or 'char', if it's signed) cannot be
passed into a <ctype.h> function unchanged, because it may have a value
that is neither inside the range of unsigned char, nor is it EOF, as the
standard dictates for the arguments of the <ctype.h> functions.
The '& 0xff' trick only works because our machines use twos-complement
for negative integers. So my vote would be to replace that
c &= 0xff
with c = (unsigned char) c;
(and a comment, maybe).
gcc -O0 seems to translate that into a 'movzbl' instruction, i.e. it zeros
the other three bytes of 'c', which is 100% equivalent to a &0xff
operation.
> ANSI says that ctype functions accept an
> int, including EOF (which cannot be casted to unsigned char; fixing that
> in v2.02 was the reason these bugs came into existence in the first
> place).
But the int may not have any negative value other than EOF. The fact that
you can get this result from the '&0xff' operation is all but obvious,
which my primary concern with that method.
Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de)
Even if all the snow were burnt, ashes would remain.
- Raw text -