[PATCH] D66664: [FIX] Nonnull is not always implied by dereferenceable

Johannes Doerfert via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Aug 23 13:56:12 PDT 2019


jdoerfert added a comment.

In D66664#1643543 <https://reviews.llvm.org/D66664#1643543>, @efriedma wrote:

> getPointerDereferenceableBytes returns some number of dereferenceable bytes.  If CanBeNull is true, that result is modified: if the pointer value is null, the number of known dereferenceable bytes is actually zero.


That is the part that is not true because we conflate two concepts, "can be a nullptr" and "is known to be deref". If the pointer value is `null` the there can well be dereferenceable bytes. And if there are dereferenceable bytes, the value can as well be `null`.

> As far as I can tell, without your patch, the function implements this logic correctly, and the callers use the result correctly.  "CanBeNull == false" doesn't mean the pointer is non-null; it means the caller doesn't have to prove the value is non-null before using the "known dereferenceable bytes" result. The parameter CanBeNull should probably be named to clarify that, though; maybe "OrNull" would be better?

I don't believe it makes sense to cling on the "null is special" concept (e.g., by naming it `OrNull`) here given that we give up on that for non-0 address spaces.
In D66618 <https://reviews.llvm.org/D66618> I made the different cases explicit.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D66664/new/

https://reviews.llvm.org/D66664





More information about the llvm-commits mailing list