Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!cbatt!cbosgd!gatech!gitpyr!thomps
From: thomps@gitpyr.UUCP
Newsgroups: comp.lang.c,comp.std.internat
Subject: Re: draft ANSI standard:  are chars signed?
Message-ID: <2787@gitpyr.gatech.EDU>
Date: Wed, 10-Dec-86 10:05:54 EST
Article-I.D.: gitpyr.2787
Posted: Wed Dec 10 10:05:54 1986
Date-Received: Sun, 14-Dec-86 01:09:36 EST
References: <1382@hoptoad.uucp> <8322@lll-crg.ARpA> <783@nscpdc.NSC.COM> <1462@hoptoad.uucp>
Organization: Georgia Institute of Technology
Lines: 30
Summary: Not really broken just not portable
Xref: watmath comp.lang.c:344 comp.std.internat:41

> > 	char	- signed or unsigned, implementation defined
> > 	unsigned char
> > 	signed char
> 
> Of course, this compromise breaks all the code that depends on chars
> being EITHER signed OR unsigned!  To be portable and "strictly
> conforming", you can't depend on =chars having signs= or =chars having no
> signs=, you just can't depend.
> 
> I would rather they had broken half the code that makes assumptions,
> rather than all of it.

It seems to me that what ANSI has done is maintain the status quo. Currently
whether or not characters are signed is implementation dependent. To write
portable code, you must make no assumptions about the signedness of characters.
The same situation will exist with the ANSI standard. Code which currently
works on a particular implementation should continue to work (unless the
implementation default is changed which seems unlikely). New code can be
written portably using signed or unsigned characters.

The solution chosen by ANSI seems to me to have broken no code so why change
to a solution which would break half. You can't expect ANSI to take 
non-portable code and magically make it portable.


-- 
Ken Thompson  Phone : (404) 894-7089
Georgia Tech Research Institute
Georgia Insitute of Technology, Atlanta Georgia, 30332
...!{akgua,allegra,amd,hplabs,ihnp4,seismo,ut-ngp}!gatech!gitpyr!thomps