Addresses of parameters (was Re: Portability of passing/operating ...)

Karl Heuer karl at haddock.ima.isc.com
Thu Oct 27 04:33:26 AEST 1988


In article <35620 at XAIT.Xerox.COM> g-rh at XAIT.Xerox.COM (Richard Harter) writes:
>In article <41337 at yale-celray.yale.UUCP> wald-david at CS.YALE.EDU (david wald) writes:
>>In article <35569 at XAIT.Xerox.COM> g-rh at 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 at haddock.isc.com), The Walking Lint



More information about the Comp.lang.c mailing list