[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