gnu@hoptoad.UUCP (12/10/86)
In article <783@nscpdc.NSC.COM>, joemu@nscpdc.NSC.COM (Joe Mueller) writes: > The committee wanted to "fix" the question of signedness of a char but > couldn't arrive at an acceptable compromise. We thought about having > chars be signed and unsigned chars unsigned but we were afraid it would > break too much code that depended on chars being unsigned. We ended up > adopting the compromise of: > 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. -- John Gilmore {sun,ptsfa,lll-crg,ihnp4}!hoptoad!gnu jgilmore@lll-crg.arpa Call +1 800 854 7179 or +1 714 540 9870 and order X3.159-198x (ANSI C) for $65. Then spend two weeks reading it and weeping. THEN send in formal comments!
news@cit-vax.UUCP (12/10/86)
Organization : California Institute of Technology Keywords: From: jon@oddhack.Caltech.Edu (Jon Leech) Path: oddhack!jon In article <1462@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes: >In article <783@nscpdc.NSC.COM>, joemu@nscpdc.NSC.COM (Joe Mueller) writes: >> The committee wanted to "fix" the question of signedness of a char but >> couldn't arrive at an acceptable compromise. We thought about having >> chars be signed and unsigned chars unsigned but we were afraid it would >> break too much code that depended on chars being unsigned. We ended up >> adopting the compromise of: >> 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. I fail to see how this choice 'breaks' ANY code. It is not possible to write portable code with either of the above assumptions now. It will not be possible under ANSI - but it will then be possible to explicitly choose signed chars if you want. What broke? If you are saying ANSI should have chosen chars to always be signed or unsigned just so currently broken code will become non-broken, I don't agree with the complaint. Who knows how much inefficiency may result? -- Jon Leech (jon@csvax.caltech.edu || ...seismo!cit-vax!jon) Caltech Computer Science Graphics Group __@/
thomps@gitpyr.UUCP (12/10/86)
> > 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
roz@l.cc.purdue.edu.UUCP (12/12/86)
In article <1462@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes: >In article <783@nscpdc.NSC.COM>, joemu@nscpdc.NSC.COM (Joe Mueller) writes: >> The committee wanted to "fix" the question of signedness of a char >> [....] >> We ended up >> adopting the compromise of: >> 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. Now I'm not claiming to be a C expert, but isn't it what's going on now, that you "just can't depend" ? Isn't it the current state of affairs that char's are either signed or unsigned, implementation defined ? If your codes *are* depending on one or the other, then they are not at all portable. >I would rather they had broken half the code that makes assumptions, >rather than all of it. Of course, unless I'm wrong, they're not breaking ANY code, since all they did was adding two more types -- signed char and unsigned char -- , not changing any current type. So apparently *no* code is broken. -- Hao-Nhien Q. Vu (pur-ee!l.cc.purdue.edu!vu) (vu@l.cc.purdue.edu) [That's "ell", not "one"]
gwyn@brl-smoke.ARPA (Doug Gwyn ) (12/15/86)
In article <1462@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes: >I would rather they had broken half the code that makes assumptions, >rather than all of it. X3J11 did not change the pre-existing situation with respect to (char) signedness. There never was a guarantee that (char) was signed, nor that it was unsigned. It will be either one or the other, defined by the implementation. There is a guarantee that the required source character set have positive values as (char)s; so far as I know, this also agrees with existing practice. Since there was no change made to the status quo, it's hard to see how this counts as "breaking code".
joemu@nscpdc.NSC.COM (Joe Mueller) (12/17/86)
In article <1462@hoptoad.uucp>, gnu@hoptoad.uucp (John Gilmore) writes: > > We ended up adopting the compromise of: > > char - signed or unsigned, implementation defined > > 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. You missed the point. The position the committee took doesn't break any code. It's just not maximally portable (strictly conforming). This code has never been portable to all systems. If you want to make this code more portable, you will have to add "signed" or "unsigned" to all of your char declarations to get the range you really want. If we had made all chars signed, it would have truely broken all the code that depended on it being unsigned. Joe Mueller ...!nsc!nscpdc!joemu
gnu@hoptoad.uucp (John Gilmore) (12/19/86)
Four or ten people have taken me to task for saying that having "char"
be either signed or unsigned has "broken code". They are right, it
doesn't break any code. It just continues to make all such code
nonportable, which is the current state of such code. Joe Mueller also
points out that the proper way to make such code portable is to add
"signed" and "unsigned" declarations such that you never declare
anything "char" where it matters.
Mea Culpa...
--
John Gilmore {sun,ptsfa,lll-crg,ihnp4}!hoptoad!gnu jgilmore@lll-crg.arpa
Call +1 800 854 7179 or +1 714 540 9870 and order X3.159-198x (ANSI C) for $65.
Then spend two weeks reading it and weeping. THEN send in formal comments! mouse@mcgill-vision.UUCP (der Mouse) (12/21/86)
In article <475@l.cc.purdue.edu>, roz@l.cc.purdue.edu (Vu Qui Hao-Nhien) writes: > Of course, unless I'm wrong, they're not breaking ANY code, since all > they did was adding two more types -- signed char and unsigned char --, > not changing any current type. So apparently *no* code is broken. Is there a compiler left that barfs on unsigned char? I think (at least in practice) they really added only one type: signed char. der Mouse USA: {ihnp4,decvax,akgua,utzoo,etc}!utcsri!mcgill-vision!mouse think!mosart!mcgill-vision!mouse Europe: mcvax!decvax!utcsri!mcgill-vision!mouse ARPAnet: think!mosart!mcgill-vision!mouse@harvard.harvard.edu