r201162 - 'nonnull(1)' on a block parameter should apply to the block's argument.
Ted Kremenek
kremenek at apple.com
Mon Jun 30 13:30:40 PDT 2014
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>
More information about the cfe-commits
mailing list