Path: utzoo!attcan!uunet!husc6!ukma!uflorida!haven!adm!smoke!gwyn From: gwyn@smoke.BRL.MIL (Doug Gwyn ) Newsgroups: comp.lang.c Subject: Re: signed/unsigned char/short/int/long Message-ID: <9002@smoke.BRL.MIL> Date: 28 Nov 88 22:08:41 GMT References: <264@aber-cs.UUCP> <8982@smoke.BRL.MIL> <8983@smoke.BRL.MIL> <277@aber-cs.UUCP> Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB)) Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 67 In article <277@aber-cs.UUCP> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: >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. But that is NOT what the dpANS says. unsigned int and signed int are also distinct types. They are guaranteed to have the same representation and alignment requirements (for the values that they share) when used as function arguments or union members, but that does not reflect on their types. >I would not agree that char has never been a length specifier for int; Certainly not in the sense that you mean for "short". "short int" is valid, but "char int" is not and never has been. char is a basic integral type (of uncertain signedness). >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). I don't know what "fuss" you refer to. Your complaint about "signed" is the first complaint I have heard. "signed" is in fact existing practice in several compilers, although not in K&R 1st Edition. It really isn't necessary for anything except "signed char". The reason it is necessary there is that "char" has explicitly been defined as being possibly signed, possibly not, depending on whatever was most efficient for the specific implementation. "signed char" provides a way to force the signed flavor in cases where it matters. The rules for promotion of types in mixed expressions really have nothing to do with "signed", since "signed int" means EXACTLY the same as "int" (for example). The complicated wording you gave for conversion rules seems to amount to much the same as in the dpANS, only less precise and less complete. You should study the examples in the Rationale document to see what subtleties are involved. >[under Grandi's proposal]... >char by itself may be either, char int and char unsigned are well defined. But that really is contrary to existing practice, as you unjustly accused "signed" of being. Try "char int" on a typical PCC and you will get an "illegal type combination" error message. >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...). The party line on trigraphs is that they are primarily meant to aid C source code interchange between systems with widely varying character sets, not as something to be used in normal programming practice -- where other approaches that are more suitable are envisioned (and allowed by the proposed standard as the first part of translation phase 1). I'm frankly not at all certain that the latter point was really widely appreciated by the committee until fairly recently, but it is now. >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". I don't think that was intended as "damning with faint praise". Dennis has in the past expressed his appreciation of the committee's work. The one thing he was unhappy about was the way we had type qualifiers set up in the second formal public review draft of the standard. This has been fixed, with help from Dennis and a few other public reviewers.