Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!haven!adm!smoke!gwyn From: gwyn@smoke.BRL.MIL (Doug Gwyn ) Newsgroups: comp.lang.c Subject: Re: signed/unsigned char/short/int/long [was: #defines with parameters] Message-ID: <9086@smoke.BRL.MIL> Date: 6 Dec 88 19:29:47 GMT References: <264@aber-cs.UUCP> <8982@smoke.BRL.MIL> <8983@smoke.BRL.MIL> <277@aber-cs.UUCP> <225@twwells.uucp> <330@aber-cs.UUCP> Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB)) Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 52 In article <330@aber-cs.UUCP> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: >First of all I wish to admit I have been inaccurate; as somebody remarked >"noalias" was only briefly in the dpANS C, and "far" and "near" never >actually made it in the official documents sent out for review. But all >were for a long time in various drafts, and as usually happens people >actually advertised "far" and "near" as examples of draft, unofficial >ANSI C conformance. Thank goodness X3J11 frustrated their efforts in the end. You're still inaccurate. "far" and "near" were never at any time in any draft of the proposed ANSI C standard. "noalias" was not in any draft other than the one sent out for the second public review. How could it be, when it had just been invented at the previous meeting and was retracted at the next? Are you just making this stuff up, or do you have drug-using advisors, or what? >As to the last point, char has been so far just a short short; a char >value can be operated upon exactly as an integer. Except that whether it acts as signed or unsigned depends on the implementation. >Historically char constants have been really the size of integer >constants... You mean "character constants"; in C they ARE integer constants specified in a certain character-oriented way. >Now I reiterate the question: why was a new keyword introduced "signed" >when it just sufficed to sanction the existing practice of some >compilers (PCC had it, more recent BSD versions fixed this "bug") to >say "int char" or better "char int"? I have never seen a C compiler that accepted "int char"; certainly Ritchie didn't intend for it to be valid. Also, char has never been guaranteed to be signed; read K&R 1st Edition. It happened to be most efficient on the PDP-11 to make it signed, but it was implemented as unsigned on some other architectures. The VAX port of the C compiler could have done it either way; signed behavior was chosen, presumably to aid in porting code developed on the PDP-11. The IBM 370 and WE 3B compilers had chars act as unsigned all along. Ritchie specifically blessed this implementation dependence in his BSTJ article on C in 1978. >Amusingly it persists even today in other compilers, among them >g++ 1.27, where interestingly "sizeof (char int)" is 4 and "sizeof >(int char)" is 1 on a 68020... I don't know what C++ rules for basic types really are, but if as I suspect g++ is getting it wrong, you should report this bug to the GNU project.