Path: utzoo!yunexus!geac!syntron!jtsv16!uunet!peregrine!elroy!ames!pasteur!agate!bionet!apple!bloom-beacon!spdcc!ima!haddock!karl
From: karl@haddock.ima.isc.com (Karl Heuer)
Newsgroups: comp.lang.c
Subject: Re: Addresses of parameters (was Re: Portability of passing/operating ...)
Message-ID: <10124@haddock.ima.isc.com>
Date: 26 Oct 88 18:33:26 GMT
Article-I.D.: haddock.10124
References: <35620@XAIT.Xerox.COM>
Reply-To: karl@haddock.ima.isc.com (Karl Heuer)
Organization: Interactive Systems, Boston
Lines: 40

In article <35620@XAIT.Xerox.COM> g-rh@XAIT.Xerox.COM (Richard Harter) writes:
>In article <41337@yale-celray.yale.UUCP> wald-david@CS.YALE.EDU (david wald) writes:
>>In article <35569@XAIT.Xerox.COM> g-rh@XAIT.Xerox.COM (Richard Harter) writes:
>>>This is a good example.  It contains two coding techniques that I do not
>>>use and, indeed, would not think of using.  The first is taking the address
>>>of a function parameter.  The second is initialization to a dynamic
>>>quantity....
>
>>I'm not sure why you consider the first of these a dubious construct.
>>(The second I am willing to consider a non-portable abbreviation for an
>>extra line of code.)

Interesting.  I recognize that some compilers get the first one wrong (when
the argument has a type which is affected by the default argument promotions),
but I've never considered it unportable to initialize auto variables to an
arbitrary expression.

>[A] parameter need not have an address.  Consider a hypothetical machine P
>which passes the first n arguments through registers.  I will grant that it
>is easy enough to put a kludge in the compiler to get around this ... but it
>is a kludge and there is no guarantee that the compiler writers will handle
>this for you (particularly in a a one pass compiler!)

The guarantee appears in the language specification.  Similarly, I feel
justified in using expression of type "char *" even though there exist
architectures which have no natural representation of pointers to objects
smaller than an int; I assume that if they're going to call it a C compiler,
the implementors will add whatever kludges are necessary to fit the language
to their machine.

>The reason that this is bad as a matter of general principles is that the
>address of a calling sequence parameter is not a meaningful thing.  Arguments
>in C are copies of the parameters passed.  The address (if it exists) is the
>address of the copy; it is not, so to speak, an address of a real object.

I've declared it as a variable; the declaration appears as part of the
function header.  It should be just as addressible as any other variable I've
declared.

Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint