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

[Daniel Dunbar]

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
>
>