Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site dataio.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxn!ihnp4!qantel!hplabs!tektronix!uw-beaver!uw-june!entropy!dataio!bright
From: bright@dataio.UUCP (Walter Bright)
Newsgroups: net.lang.c
Subject: Re: how has C bitten you?
Message-ID: <745@dataio.UUCP>
Date: Sat, 3-Aug-85 10:32:26 EDT
Article-I.D.: dataio.745
Posted: Sat Aug  3 10:32:26 1985
Date-Received: Tue, 6-Aug-85 08:33:42 EDT
Reply-To: bright@dataio.UUCP (Walter Bright)
Organization: Data I/O Corp., Redmond WA
Lines: 25

In article <5400010@prism.UUCP> matt@prism.UUCP writes:
>I sure wish that while the ANSI committee was adding "signed" to the
>language, they had standardized whether the default for "char" was
>signed or unsigned.  As long as compilers have to provide them both
>anyway, what's the harm in choosing one as the default?

The reason why some compilers default to signed chars and others
default to unsigned can be found in the instruction set of the underlying
machine. Some machines support signed chars easier than unsigned ones,
and vice versa. Some examples:

	The 8088 can only sign extend a byte to a word from the AL register,
	whereas a zero extension can cheaply be done from the AL,BL,CL
	or DL register. Thus, most 8088 C compilers default to unsigned
	chars.

	The pdpll, when reading a byte from memory, automatically sign
	extends the byte. Thus, implementing unsigned chars costs an
	extra mask instruction for each char read. Not suprisingly,
	chars default to being signed.

For most applications, it doesn't matter whether a char is signed or
not, and so it is appropriate for the compiler to select that which
can be implemented most efficiently. When it does matter, the programmer
should take care (by explicitly declaring it as signed or unsigned).