[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