Path: utzoo!utgpu!water!watmath!clyde!ima!haddock!karl
From: karl@haddock.ima.isc.com (Karl Heuer)
Newsgroups: comp.lang.c
Subject: Re: Addresses of parameters
Message-ID: <10164@haddock.ima.isc.com>
Date: 27 Oct 88 20:21:45 GMT
References: <35620@XAIT.Xerox.COM> <10124@haddock.ima.isc.com> <35664@XAIT.Xerox.COM>
Reply-To: karl@haddock.ima.isc.com (Karl Heuer)
Organization: Interactive Systems, Boston
Lines: 57

In article <35664@XAIT.Xerox.COM> g-rh@XAIT.Xerox.COM (Richard Harter) writes:
>In article <10124@haddock.ima.isc.com> karl@haddock.ima.isc.com (Karl Heuer) writes:
>>I've never considered it unportable to initialize auto variables to an
>>arbitrary expression.
>
>Well, I didn't say it was not portable -- I said that I wouldn't think of
>using it.

I was responding to the previous poster, who considered it a "non-portable
abbreviation for an extra line of code".  I agree, btw, that there are things
to be avoided in this area as a matter of style (I won't list them, lest I
start a new flame war), but I don't take it to the extreme that you do.

>>Similarly, I feel justified in using expression of type "char *" even though
>>there exist [word-based] architectures ...
>
>The cases are not similar.  Expressions of type "char *" are fundamental to
>the language.  Taking the address of a calling sequence parameter is an
>oddity ...

I think it's merely a difference in degree.  If someone tried to market an
alleged C compiler that couldn't handle "char *", they'd be laughed out of
existence.  If they get sloppy on parameter addressing, they can probably
shrug it off as a "minor bug" for a while.

>Are you sure, by the way, that such a guarantee is in the major language
>specifications?  Taking an address is not invariably guaranteed.

Yes, I'm sure.  It's implicit in K&R (which is not, and was not intended to
be, a precise language specification).  According to the dpANS (the formal
spec), the only lvalues that cannot be &'d are registers and bitfields.
(There also exist lvalues that are not modifiable, namely arrays and consts;
this is an orthogonal concept.)

>>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.
>
>{register int i; thing = &i;}

My statement stands.  Non-parameter variables are addressible if and only if
they are not declared register; the same holds for parameters.  This makes it
"just as addressible".

>[The point is] that taking the address of a parameter is not a useful kind of
>thing to do.

I'll grant that it's not all that common, but I think it can be as useful as
taking the address of an auto variable, and for the same reasons.  In effect,
a parameter *is* an auto variable which is initialized to the value of the
actual argument.

Your reasoning raises a couple of other questions.  Do you ever change the
value of a parameter variable, or do you treat it as a constant?  Do you ever
declare a formal parameter with the "register" keyword?

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