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

[Hal Finkel]

----- Original Message -----
> From: "Richard Smith" <richard at metafoo.co.uk>
> To: "Ted Kremenek" <kremenek at apple.com>
> Cc: "cfe commits" <cfe-commits at cs.uiuc.edu>
> Sent: Wednesday, February 19, 2014 8:40:18 PM
> Subject: Re: r201162 - 'nonnull(1)' on a block parameter should apply to the	block's argument.
> 
> 
> 
> 
> 
> Heh, I see what you did there :-) Here are some options:
> 
> 
> nonnull_param, required, notnull, dereferenceable

I'd like to have a dereferenceable attribute, but I don't think we have backend support for that right now (then again, maybe we don't have backend support for notnull either). AFAIK, notnull allows constant folding of comparisons against the null pointer, whereas dereferenceable would allow that plus speculative loading.

 -Hal

> 
> 
> 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
> 
> 
> 
> 
> 
> 
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory