signed/unsigned char/short/int/long

Doug Gwyn gwyn at smoke.BRL.MIL
Sat Dec 10 11:31:41 AEST 1988


In article <347 at aber-cs.UUCP> pcg at cs.aber.ac.uk (Piercarlo Grandi) writes:
>In article <9086 at smoke.BRL.MIL> gwyn at brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) 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.



More information about the Comp.lang.c mailing list