On Jun 4, 2014, at 10:30 AM, David Blaikie <[email protected]> wrote:
> On Wed, Jun 4, 2014 at 7:20 AM, Ted Kremenek <[email protected]> wrote: >> On Feb 19, 2014, at 7:58 PM, Hal Finkel <[email protected]> wrote: >> >> ----- Original Message ----- >> >> From: "Richard Smith" <[email protected]> >> To: "Ted Kremenek" <[email protected]> >> Cc: "cfe commits" <[email protected]> >> 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.
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
