Addresses of parameters

[Richard Harter]

In article <10124 at haddock.ima.isc.com> karl at haddock.ima.isc.com (Karl Heuer) writes:
>In article <35620 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.

	Well, I didn't say it was not portable -- I said that I wouldn't
think of using it.  I am not, therefore in a position to know whether it is
portable.  I (personally) don't think it is good form, portable or not.  It
does two things.  It makes the declarations order dependent, which is an
unnecessary source of complications.  It also mixes the notions of data
space allocation and assignment statements.  I prefer to keep the notions
distinct.  Call it a prejudice.

>>[A] parameter need not have an address.  Consider a hypothetical machine P
>>which passes the first n arguments through registers...

>The guarantee appears in the language specification.

*the* language specification.  Surely you jest.  

>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 cases are not similar.  Expressions of type "char *" are
fundamental to the language.  Taking the address of a calling sequence
parameter is an oddity, much as 5["foobar"] is an oddity.  One avoids
using oddities because they are intellectual clutter; the fact that you
avoid thereby one of the major ways in which compilers break is simply a
bonus.  Are you sure, by the way, that such a guarantee is in the major
language specifications?  Taking an address is not invariably guaranteed.
Indeed, taking the address of a register variable is specifically forbidden.
You may not take the address of a variable if it does not have one.  Is
this explictly stated K&R that parameters have addresses?  In H&S?  In
ANSI?

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

	Granted.  As in:

	foo(thing)
		int *thing;
	{register int i; thing = &i;}

Parameters are a different kind of thing from automatic and static variables.
There are slightly different rules for them.  Be that as it may, you didn't
address (you should excuse the expression) the point, which is that taking
the address of a parameter is not a useful kind of thing to do.

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


-- 

In the fields of Hell where the grass grows high
Are the graves of dreams allowed to die.
	Richard Harter, SMDS  Inc.