[cfe-dev] Clang ignores nonnull attributes on declarations following definitions when compiling as C++

[Tom Honermann]

On 07/13/2015 11:15 AM, Tom Honermann wrote:
> Clang (3.4-trunk) ignores nonnull attributes on declarations following
> definitions when compiling as C++, but not as C.  I presume the
> difference has to do with tentative definitions in C.
>
> A test case is below.  Recent versions of gcc and EDG both allow nonnull
> attributes on declarations following a definition, at least for this
> test case.  Is it desirable for Clang to act differently in this respect?
>
> Tom.
>
> $ cat t.c
> void (*pf)(int *p1);
> extern void (*pf)(int *p1)
>      __attribute__((nonnull));
> void f() {
>      pf(0);
> }
>
>
> # Compiling as C, no warning is emitted, the nonnull attribute
> # is present in the resulting AST:
> $ clang -c -Xclang -ast-dump t.c
> t.c:5:9: warning: null passed to a callee that requires a non-null
> argument [-Wnonnull]
>      pf(0);
>         ~^
> ...
> `-VarDecl 0x822dda0 prev 0x822dc50 <line:2:1, col:26> col:15 pf 'void
> (*)(int *)' extern
>    `-NonNullAttr 0x822de00 <line:3:20>
> ...
>
>
> # Compiling as C++, a warning is emitted and the nonnull attribute
> # is not present in the resulting AST:
> $ clang -c -Xclang -ast-dump -x c++ t.c
> t.c:3:20: warning: attribute declaration must precede definition
> [-Wignored-attributes]
>      __attribute__((nonnull));
>                     ^
> t.c:1:8: note: previous definition is here
> void (*pf)(int *p1);
>         ^
> ...
> `-VarDecl 0x82e41e0 prev 0x82e4090 <line:2:1, col:26> col:15 pf 'void
> (*)(int *)' extern
> ...
> 1 warning generated.
>
>
> # gcc (4.6.3) emits a warning when invoking *pf with a null argument
> regardless of whether the code is compiled as C or C++:
> $ gcc -Wall -c t.c
> t.c: In function 'f':
> t.c:5:5: warning: null argument where non-null required (argument 1)
> [-Wnonnull]
> $ gcc -Wall -c -x c++ t.c
> t.c: In function 'void f()':
> t.c:5:9: warning: null argument where non-null required (argument 1)
> [-Wnonnull]

I went ahead and filed a new bug for this issue: 
https://llvm.org/bugs/show_bug.cgi?id=24134

Tom.