Signed char - What Foolishness Is This!

Bennett E. Todd III bet at ecsvax.UUCP
Sat Nov 1 02:31:18 AEST 1986


In article <228 at apple.UUCP> mikes at apple.UUCP (Mike Shannon) writes:
>In <8719 at duke.duke.UUCP> jwg at duke.UUCP (Jeffrey William Gillette) writes:
>>
>>MSC 4.0 defaults 'char' to 'signed char'.  ...
>>             This works great when c = 65 ('A'), but when c = 154
>>('U'umlaut) the macro produces the following: ( (_ctype+1)[-102] & UPPER )
>> ....
>	The problem is that the u-umlaut char is being treated as negative.
>K&R, page 183, section 6.1 says "... but it is guaranteed that a member of the
>standard character set is non-negative."
>	Apple experienced the same problem with an extended character set.
>I believe that u-umlaut is part of your machine's standard character set, and
>so I would argue that MSC does not conform to K&R in this respect.

I haven't looked at MSC 4.0 yet, but I've been using MSC 3.0 for a
while, and it sounds like this hasn't changed. In the documentation, it
is exceedingly clear about this (and agrees with proper portable
programming practice for UNIX systems):

	int isascii(c);	/* test for ASCII character (0x00-0x7F) */
[...]
	"The isacii routine produces a meaningful result for all integer
	 values. However, the remaining routines produce a defined result
	 only for integer values corresponding to the ASCII character
	 set (that is, only where isascii holds true) or for the non-ASCII
	 value EOF (defined in stdio.h)."

I'd say MSC is completely in the right on this one; C is a portable
programming language, and MSC is the best implementation I've seen for
porting code to the PC. The documentation is clear; they implement a C
environment with an ASCII, not "Extended ASCII", character set. If
portability is not of interest, then you can hack up the ctype macros,
or whatever. However, portable programs should always use an idiom like

	if (isascii(c) && isupper(c)) {

or whatever. Program defensively! Write programs that run *anywhere*,
and check for anything that might possibly go wrong. Then give them away
for free.

-Bennett
-- 

Bennett Todd -- Duke Computation Center, Durham, NC 27706-7756; (919) 684-3695
UUCP: ...{decvax,seismo,philabs,ihnp4,akgua}!mcnc!ecsvax!duccpc!bet
BITNET: DBTODD at TUCC.BITNET -or- DBTODD at TUCCVM.BITNET -or- bet at ECSVAX.BITNET



More information about the Comp.lang.c mailing list