Path: utzoo!attcan!uunet!mcvax!ukc!dcl-cs!aber-cs!pcg From: pcg@aber-cs.UUCP (Piercarlo Grandi) Newsgroups: comp.lang.c Subject: Re: signed/unsigned char/short/int/long [was: #defines with parameters] Summary: Sorry, I used the wrong terminology... -- signed is the culprit Message-ID: <277@aber-cs.UUCP> Date: 27 Nov 88 14:35:55 GMT References: <264@aber-cs.UUCP> <8982@smoke.BRL.MIL> <8983@smoke.BRL.MIL> Reply-To: pcg@cs.aber.ac.uk (Piercarlo Grandi) Distribution: eunet,world Organization: CS Dept., University College of Wales, Aberystwyth, UK Lines: 83 X-Disclaimer: Any statement is purely personal. I am happy I managed to sidetrack the sterile discussion on macros in cpp into something dearer to my heart (can you say "axe to grind" ? I can ;->...). I am relieved that the dpANS does not imply prescience and telepathy are required in cpp or the compilers to understand which macros are parameterless and which are not :-) :-)... On the other hand the substance of my point on unsigned/int remains; I apologize to Doug Gwin for having used the wrong terminology. What I really was unhappy with in dpANS (among many other things...) is that signed has been introduced as a new keyword, and I ought to have said unsigned/signed, not unsigned/int. As I understand it, this means that char,short,int,long are distinct types, whereas unsigned and signed are type modifiers. In a sense then, the view of dpANS is that unsigned [int] and [signed] int are the same type, only that one has a sign and the other hasn't. Clearly this mostly is a matter of emphasis, in that unsigned short and signed short are distinct types, as would be short unsigned and short int, but it is quite important to note that in dpANS there is an explicit affinity between unsigned and signed short, not between short and long unsigned, even if we concede that type modifiers create new types, instead of merely subtypes. I would not agree that char has never been a length specifier for int; before dpANS, C was defined by Ritchie's and Johnson's compilers (in a sense even K&R was just the manual for the compilers). In both compilers, and reading carefully K&R, one has the strong impression that, beyond a somewhat artificial distinction between integral and integer types, char was always meant to be a kind of short short int, and indeed one can apply to a char all the same operations one can apply to an integer; also the rules about lengtheneing of char and short in many contexts, and the common use of int where char could have been used, tend to reinforce the impression. I would also not agree that in this matter dpANS respected existing practice; the introduction of the signed modifier is certainly an innovation, and a confusing one as well (judging from all the fuss about it and char). In Johnson's compiler instead one can fully use char,short,long as type modifiers, and int and unsigned as based types, and I regard this (in my never humble opinion) as the most natural thing to do, and one that would not have required the introduction of signed. I understand that using a compiler as definition of a language is not kosher, but before dpANS this was the way (fortunately :->). Using this interpretation, there is little argument about adopting a "[un]signed preserving" or "value preserving" rule; the only rules are that conversion from a shorter to a long form of the same type results in no changes, and tyhe same applies when a longer value is shortened to a length that can represent it, and conversion across the two base types is defined only if the source unsigned is not too large or the source int is not too large or negative; anything else is machine dependent, except that truncations to a length of unsigned must respect the rules of modular arithmetic. This interpretation may not be what Ritchie, Johnson and K&R meant, but it is consistent with them (well, I admit that saying char int and char unsigned is somewhat funny, but you can get used to it ;-}), especially with the point that unsigned obeys a different type of laws of arithmetic (modular) than int (algebraic), thus distinguishing them more forcefully than differences of range, that after all are just accidents of implementation. Note also that there is no need of a signed keyword to disambiguate between variations of char in this interpretation; char by itself may be either, char int and char unsigned are well defined. As to the rest of dpANS, I will not rekindle spent discussions, except for a cheap leer at trigraphs :-) :-) (I understand that the committee were more or less forced to include them, so it is not wholly their fault...). As Ritchie said (more or less) in an interview to Computer Language: "dpANS C is the best standard that could have come out of a committee". -- Piercarlo "Peter" Grandi INET: pcg@cs.aber.ac.uk Sw.Eng. Group, Dept. of Computer Science UUCP: ...!mcvax!ukc!aber-cs!pcg UCW, Penglais, Aberystwyth, WALES SY23 3BZ (UK)