Signed char - What Foolishness Is This!
Jeffrey William Gillette
jwg at duke.UUCP
Thu Oct 16 22:26:49 AEST 1986
[]
OK, I've been bitten. I admit it.
MSC 4.0 defaults 'char' to 'signed char'. For standard ASCII there
is no difference between 'signed char' and 'unsigned char'. When I
get to IBM's extensions to ASCII the situation is much different!
<ctype.h> makes the following #define:
#define isupper(c) ( (_ctype+1)[c] & _UPPER )
where 'UPPER' is a bit mask used in a table of character definitions
('_ctype'). This works great when c = 65 ('A'), but when c = 154
('U'umlaut) the macro produces the following:
( (_ctype+1)[-102] & UPPER )
an obviously foolish bug.
The problem here lies with Microsoft. The #defines in <ctype.h>
are sloppy. The example above should have been
#define isupper(c) ( (_ctype+1)[(unsigned char)c] & _UPPER )
Beyond this particular and annoying consequence of MS's decision
to make 'char' = 'signed char', I have two more general questions
(thus the post to net.lang.c).
1) Do other C compilers make 'char' a signed quantity by default?
2) What possible justification is there for this default? Is not
'char' primarily a logical (as opposed to mathematical) quantity? What
I mean is, what is the definition of a negative 'a'? I can understand
the desirability of allowing 'signed char' for gonzo programmers who
won't use 'short', or who want to risk future compatibility of their
code on the bet that useful characters will always remain 7-bit entities.
Peace,
Jeffrey William Gillette
Humanities Computing Facility
Duke University
duke!jwg
--
Jeffrey William Gillette uucp: mcnc!duke!jwg
Humanities Computing Project bitnet: DYBBUK @ TUCCVM
Duke University
More information about the Comp.lang.c
mailing list