r201162 - 'nonnull(1)' on a block parameter should apply to the block's argument.

Richard Smith richard at metafoo.co.uk
Wed Feb 19 18:40:18 PST 2014


Heh, I see what you did there :-) Here are some options:

  nonnull_param, required, notnull, dereferenceable

On Mon, Feb 17, 2014 at 8:09 PM, Ted Kremenek <kremenek at apple.com> wrote:

> Since this attribute hasn't been available before in this position (except
> in GCC), I think exploring an alternate spelling is interesting.  What
> would you propose?
>
> On Feb 17, 2014, at 4:41 PM, Richard Smith <metafoo at gmail.com> wrote:
>
> Yeah, I think that'd mostly work. But be careful about this case:
>
> template<typename T>
> void f(T *p __attribute__((nonnull))) {
>   p(0); // #1
> }
> void g() { f<void(int *q)>(0); } // #2
>
> Here again, GCC warns on #1 and Clang warns on #2. If we want to keep
> 'nonnull' as the spelling for this new thing, I think we should keep
> warning on #2. (But I do wonder if we should come up with a new name for
> this, rather than picking something that collides with an existing GCC
> attribute, even if only in corner cases.)
>
> On Mon Feb 17 2014 at 4:21:49 PM, Jordan Rose <jordan_rose at apple.com>
> wrote:
>
>> +Ted.
>>
>> I'm guessing we should stick with GCC's interpretation when the parameter
>> is a function or block pointer, but maybe have a warning, and a fix-it for
>> both possible interpretations.
>>
>> Jordan
>>
>>
>> On Feb 17, 2014, at 15:52, Richard Smith <metafoo at gmail.com> wrote:
>>
>> 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.
>>
>> On Tue Feb 11 2014 at 9:40:01 AM, Aaron Ballman <aaron at aaronballman.com>
>> wrote:
>>
>> On Tue, Feb 11, 2014 at 12:37 PM, Jordan Rose <jordan_rose at apple.com>
>> wrote:
>> >
>> > On Feb 11, 2014, at 9:36 , Aaron Ballman <aaron at aaronballman.com>
>> wrote:
>> >
>> > +    if (D->getFunctionType()) {
>> > +      handleNonNullAttr(S, D, Attr);
>> > +    } else {
>> > +      S.Diag(Attr.getLoc(), diag::warn_attribute_nonnull_parm_no_args)
>> > +        << D->getSourceRange();
>> > +    }
>> >
>> >
>> > Minor nit about the style -- shouldn't be using the curly braces here.
>> >
>> >
>> > Uh...hm. I tried it without the curly braces, but it looked very strange
>> > with the << dangling there. Should I add a dummy comment to justify it?
>>
>> I'm not too keen on dummy comments. If you think it's ugly without the
>> braces, I'm fine with leaving them. :-)
>>
>> ~Aaron
>> _______________________________________________
>> cfe-commits mailing list
>> cfe-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140219/4d6d0f93/attachment.html>


More information about the cfe-commits mailing list