address of function

Karl Heuer karl at haddock.ima.isc.com
Fri Jun 16 12:46:48 AEST 1989


In article <10361 at socslgw.csl.sony.JUNET> diamond at csl.sony.junet (Norman Diamond) writes:
>In article <1817 at auspex.auspex.com> guy at auspex.auspex.com (Guy Harris) writes:
>>["int this[100], *that = &this;" is not legal ANSI C]
>
>Oh I'm so glad ANSI is standardizing existing practices instead of
>inventing new RESTRICTIONS.  This rule won't break much existing,
>FORMERLY UNBROKEN source code, now will it?  :-S  (sarcasm)

No, it won't break any correct code, and it removes a restriction rather than
adding one.  Pre-ANSI C did not allow one to apply "&" to an array (see K&R1,
p. 94, next to last paragraph).  Perhaps you're thinking of the "feature" that
certain compilers flag this as a warning only, and ignore the "&".

>Could one also do it in this way?
>	int	this[100], *that = (int *)&this;
>	int	this[100], *that = (void *)&this;

I suppose that would work, but why don't you just write "that = &this[0]" (or
even "that = this"), if that's your intent?

>i.e.:  when a cast implies an assignment to an anonymous temporary, it
>becomes a non-lvalue -- ok; but does it also become a non-constant?

I can't think of any context in which the language cares whether an rvalue is
a "constant" or not.

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