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

[Chris Torek]

In article <35620 at XAIT.Xerox.COM> g-rh at XAIT.Xerox.COM (Richard Harter) writes:
>...  The technical reason is that a calling sequence parameter need not
>have an address.  Consider a hypothetical machine P which passes the
>first n arguments through registers.  Taking the address of such an
>argument would then be equivalent to taking the address of a register.

(Actually, the latter is possible on some machines---e.g., Pyramids, some
PDP-11s.)

>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
>one pass compiler!)

I would not call it a kludge---among other things, it has been
legislated in by the dpANS for C---and I would claim that it is no
harder in a one-pass compiler than in a multi-pass compiler.  It is,
however, true that some compilers have been known to get it wrong, so
that, for instance, the following program writes NULs on certain
Sun---ahem, I mean 68000-based machines :-)  (I think the *original*
non-paging Sun 1 V7ish compiler had the bug):

	print(c) char c; { (void) write(1, &c, 1); }

>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.

In some languages, perhaps.  In C, no: the address of a parameter is
the address of a variable.  Parameter variables should act just like
any other local variable.  If the natural calling sequence of the
machine does not provide this, the compiler should take whatever steps
are necessary to make it appear so.  Fortunately, the dpANS agrees with
me this time. . . . :-)
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris at mimsy.umd.edu	Path:	uunet!mimsy!chris