[cfe-dev] Taking the address of an Objective-C @selector expression
Jonathan Roelofs
jonathan at codesourcery.com
Wed Apr 29 08:31:57 PDT 2015
On 4/27/15 12:21 PM, Tom Honermann wrote:
> Objective-C @selector expressions yield an rvalue. However, Clang
> (trunk, r234313) allows taking the address of such an expression:
>
> $ cat t.m
> void f() {
> @selector(AMethod);
> &@selector(AMethod);
> }
>
> $ clang --version
> clang version 3.7.0 (trunk 234313)
> Target: x86_64-unknown-linux-gnu
> Thread model: posix
>
> $ clang -w -c t.m; echo $?
> 0
>
> Gcc (4.8.0) rejects:
> $ gcc -c t.m
> t.m: In function ‘main’:
> t.m:5:20: error: lvalue required as unary ‘&’ operand
> printf("%p\n", &@selector(AMethod));
> ^
>
> I presume acceptance is a Clang bug. Any dissenters?
Looks like it's intentional, but only to match an older GCC:
https://llvm.org/bugs/show_bug.cgi?id=7390
I agree with you, I think it should yeild an rvalue. Having it as a
non-const lvalue allows for this kind of weirdness:
*&@selector(AMethod) = @selector(BMethod);
which seems 'wrong' in the same way that this is:
@selector(AMethod) = @selector(BMethod);
It seems GCC was fixed in the opposite direction since PR7390. Do you
happen to know when that happened?
Cheers,
Jon
>
> Tom.
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
--
Jon Roelofs
jonathan at codesourcery.com
CodeSourcery / Mentor Embedded
More information about the cfe-dev
mailing list