🚀 go-pugleaf

[]

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