-
Notifications
You must be signed in to change notification settings - Fork 12.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tracking issue for const <*const T>::is_null
#74939
Comments
That's not entirely correct. It will at some point be possible to create out-of-bounds raw pointers in const-eval (it might be possible already with enough hacks, I am not sure). Once that is possible, a pointer could be offset enough such that it is NULL at run-time but still non-NULL when checked during CTFE -- we cannot know if out-of-bounds pointers are NULL as that depends on their concrete base address. |
So, some examples that we ran reliably check:
The problematic case Another alternative is to panic if no exact solution is known (this can be done in a way that it compiles away to nothing at runtime) Basically the options are:
|
Make `<*const T>::is_null` const fn r? @RalfJung cc @rust-lang/wg-const-eval tracking issue: rust-lang#74939
As a user, this seems the most natural to me.
In general, panicking when doing something fundamentally non-const a |
Is there anything blocking stabilization of this? This also blocks |
We still need to decide how "maybe null" pointers should be handled, see the discussion above.
|
This is tracking
#[feature(const_ptr_is_null)]
.Comparing pointers in const eval is dangerous business.
But checking whether a pointer is the null pointer is actually completely fine, as Rust does not support items being placed at the null address. Any otherwise created null pointers are supposed to return
true
foris_null
anyway, so that's ok. Thus, we implementis_null
asptr.guaranteed_eq(ptr::null())
, which returns true if it's guaranteed thatptr
is null, and there are no cases where it will return false where it may benull
, but we don't know.The text was updated successfully, but these errors were encountered: