Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!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: <9131@smoke.BRL.MIL> Date: 10 Dec 88 01:31:41 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> <9086@smoke.BRL.MIL> <347@aber-cs.UUCP> Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) ) Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 28 In article <347@aber-cs.UUCP> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: >In article <9086@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) ) writes: > You're still inaccurate. "far" and "near" were never at any time in > any draft of the proposed ANSI C standard. >Just a moment! I have just apologized saying that my inaccuracy was to imply >that near and far eventually made it into dpANS. I acknowledge that they did >not make it there, still at one time (fairly long ago) they were considered >to be going to be part of ANSI C (yes, I know that ANSI C does not yet >exist), and the usual trade interests advertised (they shouldn't have done >it, I know) these as ANSI conforming features of their compiler. I still want to know where you get that idea. There has never been any reason to think that "near" and "far" were in any sense related to ANSI C. I don't know how much plainer I could make it than in my sentence cited above. I would like to see some evidence that vendors really did advertise their multiple 808x memory-model support features of their C compilers as in any way related to "ANSI C". As to your insistence that C integral types should be respecified to accomplish no more than they current do other than to satisfy your personal sense of aesthetics, all I can say is that X3J11 did not make changes to the existing C definition and practice without good reason, and such a rearrangement would violate both. Nowhere did I imply that you hadn't read K&R 1st Ed., but it does seem to me that you never accepted it. As another poster has commented, before you suggest what C "should" be, you are obliged to understand what it is. You are free to design and promote your own programming language, but please don't confuse that with C.