Path: utzoo!attcan!uunet!taumet!steve
From: steve@taumet.com (Stephen Clamage)
Newsgroups: comp.lang.c
Subject: Re: characters
Message-ID: <459@taumet.com>
Date: 20 Sep 90 14:51:07 GMT
References: <13680@hydra.gatech.EDU> <2517@idunno.Princeton.EDU> <1990Sep18.162407.15525@zoo.toronto.edu> <2657@idunno.Princeton.EDU>
Organization: Taumetric Corporation, San Diego
Lines: 39

pfalstad@phoenix.Princeton.EDU (Paul John Falstad) writes:

>The third option is to just remember that chars are signed and watch out
>for problems caused by the sign extension.  Hmmm.  But complaining is so much
>easier...

The best option is not to write code which depends on the signed-ness of
chars.  The primary error is writing code which uses chars as tiny
integers.  In most cases, if you examine the resulting code, you will
find that this makes for no savings in code space, and often the code
is bigger and slower than if you just used ints (or possibly shorts)
instead.  If you have a large array of these things, there will be a
data savings by using chars.  To be safe, never use values outside
the range 0-127 with type char.

>Incidentally, someone sent me mail saying that neither K&R nor ANSI
>specify that chars must be signed.  True?

True.
K&R 1, section 6.1 in the Reference Manual, says:
	"Whether or not sign-extension occurs for characters is
	machine dependent ... Of the machines treated by this
	manual, only the PDP-11 sign-extends."
ANSI Standard, section 3.1.2.5, says of objects of type char:
	"... the behavior is implementation-defined: the values
	are treated as either signed or nonnegative integers."
The reason for this is that hardware varies as to whether
sign-extension is more expensive than zero-padding.  The idea was to
allow the compiler to generate the most efficient code when "plain"
char was specified.

>All the implementations I've come across have chars signed,
>however, which is the only fact I'm interested in.

Until you use an implementation where chars are unsigned and your
code stops working.  Your interests will then broaden.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com