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