[cfe-commits] r79041 - /cfe/trunk/lib/Sema/SemaDeclAttr.cpp

[Ted Kremenek]

Daniel, Eli,

I agree with the both of you.  The last patch I committed was just a  
stop gap to follow GCC's behavior.  I think that the calling  
convention attributes, noreturn, malloc, etc., should all be treated  
as qualifiers on the type.  That's the only way we're going to handle  
these uniformly and correctly.

Ted

On Aug 14, 2009, at 6:35 PM, Daniel Dunbar wrote:

> I have to admit to not really following this discussion, but one thing
> that may be worth pointing out is that this same issue exists with
> calling conventions, where it becomes much more important. I believe
> that gcc treats the attribute in that case as being part of the type,
> which means things like arrays of function pointers with alternate
> calling conventions work. Right now we completely drop that on the
> floor, which is bad...
>
> - Daniel
>
> On Fri, Aug 14, 2009 at 3:48 PM, Ted Kremenek<kremenek at apple.com>  
> wrote:
>> On Aug 14, 2009, at 3:38 PM, Eli Friedman wrote:
>>
>> On Fri, Aug 14, 2009 at 3:30 PM, Chris Lattner<clattner at apple.com>  
>> wrote:
>>
>> On Aug 14, 2009, at 3:20 PM, Eli Friedman wrote:
>>
>> On Fri, Aug 14, 2009 at 3:12 PM, Ted Kremenek<kremenek at apple.com>  
>> wrote:
>>
>> Unless I'm mistaken, this breaks constructs like the following:
>>
>> __attribute((malloc)) void *(*f)();
>>
>> -Eli
>>
>> I implemented handling of this case, but I noticed that GCC actually
>>
>> rejects
>>
>> attribute 'malloc' being applied to function pointers ("warning:  
>> 'malloc'
>>
>> attribute ignored").  Should we do the same in Clang?  For function
>>
>> pointers, the malloc attribute really a property of the pointer  
>> type, not
>>
>> the declaration, but apparently GCC doesn't even reason about that.
>>
>> I think it's better to be self-consistent here over being consistent
>>
>> with gcc, as long as we don't break compatibility.  Function
>>
>> attributes are confusing enough without making different attributes
>>
>> act differently.
>>
>> The problem is that this attribute is really a decl attribute, not  
>> a type
>>
>> attribute.  If I have two functions with the same prototype (but  
>> one is
>>
>> attribute malloc) I should be able to assign them to the same  
>> function
>>
>> pointer, no?  If we made it part of the type system, we'd have to  
>> consider
>>
>> the attribute for assignment compatibility etc.
>>
>> How is malloc different from noreturn in this regard?
>>
>> There are two points here.  First, the 'malloc' attribute is a
>> GCC-extension, and if that attribute only applies to function  
>> declarations
>> that is at least self-consistent.  Limiting, but self-consistent.   
>> Other
>> than generalizing the attribute (which might be nice from a  
>> programming
>> language theory point of view) there is no code out there that uses  
>> more
>> functionality on that attribute than GCC provides.
>> As for 'noreturn', Clang's handling of it is incorrect.  Consider:
>> $ cat t.c
>> __attribute((noreturn)) void *(*fptr)();
>> void *(*gptr)();
>> void bar() {
>>   gptr = fptr;
>> }
>> $ gcc -fsyntax-only t.c
>> t.c: In function ‘bar’:
>> t.c:5: warning: assignment makes qualified function pointer from  
>> unqualified
>> $ clang -fsyntax-only t.c
>> (nothing)
>> I'm not certain what GCC is doing under the hood, but it appears that
>> (unlike Clang) GCC is reasoning about 'noreturn' as a qualifier on  
>> the type.
>>  That doesn't appear to be the case with 'malloc'.  Perhaps that's  
>> just how
>> it was implemented in GCC, and perhaps they both should be handled as
>> qualifiers.  The upshot is that while Clang eats code where  
>> 'noreturn' is
>> attached to a function pointer, it doesn't handle it correctly.
>> _______________________________________________
>> cfe-commits mailing list
>> cfe-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>>
>>