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

[Hal Finkel]

----- Original Message -----
> From: "Ted Kremenek" <kremenek at apple.com>
> To: "David Blaikie" <dblaikie at gmail.com>
> Cc: "Hal Finkel" <hfinkel at anl.gov>, "Richard Smith" <richard at metafoo.co.uk>, "Jordan Rose" <jordan_rose at apple.com>,
> "cfe commits" <cfe-commits at cs.uiuc.edu>
> Sent: Monday, June 30, 2014 3:30:40 PM
> Subject: Re: r201162 - 'nonnull(1)' on a block parameter should apply to the block's argument.
> 
> 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.

+1 -- We should have a separate attribute for dereferencibility.

 -Hal

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