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

[Ted Kremenek]

On Jun 4, 2014, at 10:30 AM, David Blaikie <dblaikie at gmail.com> wrote:

> On Wed, Jun 4, 2014 at 7:20 AM, Ted Kremenek <kremenek at apple.com> wrote:
>> On Feb 19, 2014, at 7:58 PM, Hal Finkel <hfinkel at anl.gov> wrote:
>> 
>> ----- 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.
>> 
>> 
>> ... getting back to this.
>> 
>> How is "dereferenceable" different than "nonnull_param"?  I'd prefer the
>> latter since it aligns with the other user attributes for this concept that
>> we already have.
> 
> Pointers one-past-the-end of an array are non-null, but not dereferenceable.

Interesting.  Good point.  Do we want to capture that semantic difference here?  That seems to overload the intention of this attribute (which was explicitly about nullness).  I personally really prefer we keep this about null.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140630/6e2fc1d8/attachment.html>