NetNews Usenet Archive 1992 #18/NN_1992_18.iso/spool/comp/lang/c/12499

Text File | 1992-08-18 | 4.7 KB | 100 lines

Newsgroups: comp.lang.c
Path: sparky!uunet!usc!rpi!gatech!concert!sas!mozart.unx.sas.com!sasghm
From: [e-mail] (Gary Merrill)
Subject: Re: Pointer/address reluctance
Originator: [e-mail]
Sender: [e-mail] (Noter of Newsworthy Events)
Message-ID: <[e-mail]>
Date: Tue, 18 Aug 1992 18:45:16 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Nntp-Posting-Host: theseus.unx.sas.com
Organization: SAS Institute Inc.
Lines: 86


In article <[e-mail]>, [e-mail] (Peter van der Linden) writes:
|> From: [e-mail] (Gary Merrill)
|> >     An address constant in C begins with an ampersand.
|>
|> Actually, the above statement is not accurate.  Address constants

This was an example and not an attempt at a definition.

|> are also created implicitly, with no ampersand, by the use of an
|> expression of array or function type.

But you see this very claim would be *incoherent* if addresses and
address constants were the *same thing*.  It is not true, for example,
that *addresses* are created implicitly.

On rereading section 3.4 I do have some sympathy for your confusion
since the standard speaks in terms of "address constant" rather
than "address constant expression".  (Compare this to the immediately
preceding paragraph in which "arithmetic constant expression" is
discussed.)  Things would be clearer (and more accurate) at this
point in the standard if the language read "An address constant
expression shall have pointer type"  rather than "An address constant
is a pointer".  I believe I have fallen into the trap myself by using
the phrase "address constant" when "address constant expression" is
the proper locution.

|>
|> Even if the statement were accurate, it does not disprove my point
|> any more than saying that "floating point numbers have a dot".

Floating numbers don't have dots -- unless by 'number' you really
mean 'numeral'.  But I think you really must understand the distinction
at this point.  Please note that the standard does not refer to
floating point *numbers* but to floating point *constants*.  (There
is a 'number, floating-point' entry in the index, but I cannot see
where the term is ever used in the text.  The standard is careful
to speak of 'types' and 'constants', but not 'numbers'.  There is
a reason for this.)


|> We have a certain ASCII notation for convenience, but what we are
|> really talking about is the entity on (abstract if you like)
|> hardware.

And what do we use to talk *about* it?  And is what we use to talk
*about* it different what *what we talk about*?

|> My point is that it doesn't do much good to try to be more abstract
|> than the ANSI C standard; the ANSI C standard is happy with asides
|> and references to addresses.   You could be too.

But you have not shown this about the standard.  And in fact you
can't, because it is not true.  Please cite references in the standard
where it speaks of addresses rather than address constants or address
constant expressions.  The only section that is even remotely confusing
is 3.4 (which started you down the road to ruin).  And even then, there
is no *equivalence* claimed between pointers and address constants.
While one might be inclined to say, on the basis of the pathological
paragraph that "Every address constant is a pointer", it is clear
that the converse ("Every pointer is an address constant") is neither
intended or true.

I could not be happy with "asides and references to addresses" (even
if these were in the standard).  I have to figure out how to represent
pointers on existing and future archictures -- and do it in such a
way that the resulting compiler is ANSI conformant.  Requiring me
to implement a pointer as an address would make this task impossible.
This is precisely why ANSI does not dictate the semantics of pointers
in terms of addresses.  You may be satisfied to exclude from
consideration machines with architectures that you believe are "odd",
but the equivalence you wish to impose would prohibit C from being
implemented on some machines (in fact, as I have pointed out in
specific examples, some very real machines in use today).  The
committee was quite concerned during its deliberations to avoid such
a consequence.  The standard is not something compiler writers and
vendors read to get inspiration and hints about implementation. It
is something that demands conformance, and as such has no room for
"asides and references".



--
Gary H. Merrill  [Principal Systems Developer, C Compiler Development]
SAS Institute Inc. / SAS Campus Dr. / Cary, NC  27513 / [phone]
[e-mail] ... !mcnc!sas!sasghm