Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!henry
From: henry@utzoo.UUCP (Henry Spencer)
Newsgroups: net.lang.c,net.micro.pc
Subject: Re: Signed Chars - What Foolishness Revisited!
Message-ID: <7298@utzoo.UUCP>
Date: Fri, 7-Nov-86 15:03:19 EST
Article-I.D.: utzoo.7298
Posted: Fri Nov  7 15:03:19 1986
Date-Received: Fri, 7-Nov-86 15:03:19 EST
References: <8776@duke.duke.UUCP>, <26@asi.UUCP>
Organization: U of Toronto Zoology
Lines: 56

> 1.  Since the "c" language has an "unsigned" modifier, and not a "signed"
>     modifier, I would much rather have a signed character by default and
>     be able to define it to be "unsigned char" if needs be.

Would you still feel this way if all manipulations of signed char took
three times as long as those of unsigned char?  It can happen.

All members of this debate please attend to the following.

- There exist machines (e.g. pdp11) on which unsigned chars are a lot less
	efficient than signed chars.

- There exist machines (e.g. ibm370) on which signed chars are a lot less
	efficient than unsigned chars.

- Many applications do not care whether the chars are signed or unsigned,
	so long as they can be twiddled efficiently.

- For this reason, char is intended to be the more efficient of the two.

- Many old programs assume that char is signed; this does not make it so.
	Those programs are wrong, and have been all along.  Alas, this is
	not a comfort if you have to run them.

- The Father, the Son, and the Holy Ghost (K&R, H&S, and X3J11 resp.) all
	agree that a character of the machine's normal character set MUST
	appear positive.  Given that the IBM PC has, I understand, a full
	8-bit character set, this means that a PC compiler which treats
	char as signed is wrong, period.  This should be documented as, at
	the very least, a deviation from K&R.

- The "unsigned char" type exists (in most newer compilers) because there
	are a number of situations where sign extension is very awkward.
	For example, getchar() wants to do a non-sign-extended conversion
	from char to int.

- X3J11, in its semi-infinite wisdom, has decided that it would be nice to
	have a signed counterpart to "unsigned char", to wit "signed char".
	Therefore it is reasonable to expect that most new compilers, and
	old ones brought into conformance with the yet-to-be-issued standard,
	will give you the full choice:  signed char if you need signs,
	unsigned char if you need everything positive, and char if you don't
	care but want it to run fast.

- Given that many compilers have not yet been upgraded to match even the
	current X3J11 drafts, much less the final endproduct (which doesn't
	exist yet), any application which cares about signedness should use
	typedefs or macros for its char types, so that the definitions can
	be revised later.

- The only things you can safely put into a char variable, and depend on
	having them come out unchanged, are characters from the native
	character set and small *positive* integers.
-- 
				Henry Spencer @ U of Toronto Zoology
				{allegra,ihnp4,decvax,pyramid}!utzoo!henry