Rather than contort GNU attributes into an expression context, I'd rather just
encourage the parameter forrm of __attribute__((nonnull)) that we added a while
back:
^(int *p1 __attribute__((nonnull))) {}(0);
...although admittedly that doesn't warn either at the moment.
(There's also still a hole with this syntax, which Richard pointed out a long
time ago:
> This still seems to be GCC-incompatible. Per the GCC documentation,
> "__attribute__((nonnull))" on a pointer-to-function parameter means that all
> of *that* function's parameters can't be null. For instance:
>
> void f(int (*p)(int *a, int *b) __attribute__((nonnull))) {
> if (p)
> p(0, 0); // #1
> }
> void g() { f(0); } // #2
>
> GCC warns on line #1, Clang warns on line #2.
...and then we never got around to doing anything about.)
There's also Apple's nullability specifiers: ^(int * __nonnull p1) {}(0), but
those haven't been integrated yet, even though it seemed like most people were
happy with the proposal. (Doug's been quite busy over here.) These aren't quite
the same, though, because they don't affect codegen.
Jordan
> On Apr 29, 2015, at 11:59 , Aaron Ballman <[email protected]> wrote:
>
> PR23416 points out that we currently diagnose nonnull properly on a
> block declaration, but not on a block expression. Specifically:
>
> void(^bp)(int *) __attribute__((nonnull(1)));
> void f() {
> bp(0); // Diagnose this already
> ^(int *p1) __attribute__((nonnull(1))) {}(0); // Not diagnosing this
> }
>
> It seems reasonable and relatively straight-forward to support the
> BlockExpr case as well. The attached patch is a stab at implementing
> support for this, but since my ObjC-fu is weak (at best), I am
> wondering if I'm missing something.
>
> Thanks!
>
> ~Aaron
> <NonnullBlockExpr.patch>
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
