Repository navigation
"!" is the only type that is unsafe to raw-ptr-deref into a "_" pattern #79735
Description
Activity
One possible explanation of this behavior is that "it is UB to create a place of an uninhabited type". That would be a rather surprising special case, I think, but I could get behind this since I am actually proposing to similarly treat uninhabites types specially for
&Tvalidity (see rust-lang/unsafe-code-guidelines#77).However, under that explanation, the following code has UB:
enum Void {} fn foo(ptr: *const Void) { let _ = *ptr; } foo(&3 as *const _ as *const _);
And yet this is all accepted as safe code. So I think something is very wrong here.
Reacted by Elichai Turkel and Julian GanzShould this be nominated?
Reacted by tesujiIs this what is happening with #77694 ?
@DutchGhost I don't think so, there is no
_pattern there.Reacted by DutchGhostWe discussed this in our @rust-lang/lang meeting today. Clearly the current behavior is unsound. The question is what behavior we expect. There seem to be two related questions:
- Should
let _ = *foobe unsafe whenfoois a raw pointer, independent of everything else?- The general feeling was "yes, unsafe ought to be syntactic", and this is a regression from the move to MIR-based unsafety checking. @scottmcm is planning to file an issue on this. [scottmcm: it's Unsafe checking skips pointer dereferences in unused places #80059]
- Should
let _ = *foobe UB iffoois not a valid pointer?- Right now it is inconsistent, with that ultimately depending on the type of the referent, seems not great
let _ = placeis generally a no-op, but it does evaluateplacefor side-effects- so the question perhaps is whether evaluating
*foo(wherefoois a raw pointer) to a place has the side effect of asserting thatfoois a valid pointer which could be loaded, even though we are not currently loading
Does that analysis sound about right to you, @RalfJung? (It doesn't yet say the answers to those questions, especially the second one)
- Should
Yes that sounds about right, modulo the vagueness of the term "valid pointer". ;)
One way to look at this is by being explicit about place-to-value coercions (
p2v). The regularlet x = *ptrthen becomeslet x = p2v(*ptr);
Now there are two axes we can adjust:
- Does
let _ = *ptrperform a place-to-value coercion or not? If yes, certainly the ptr needs to be as valid as inlet x = *ptras the same things are happening. - What exactly does the mere construction of the place
*ptr, without being followed by a p2v, require in terms of validity? Does the ptr need to be dereferencable (so far I always assumed the answer is yes), does it need to point to data that is valid for the place's type (so far I always assumed the answer is no)? Does this depend on the type ofptr, i.e., do we have "raw places" whose construction is governed by different rules?
One aspect to consider for the second question is expressions like
&(*ptr).fieldand&raw (*ptr).field, where there is no implicit place-to-value coercion (assuming here thatptris a value expression). Any validity requirement we impose on place construction will also be in force here.&raw (*ptr).fieldcurrently compiles togetelementptr inbounds, and if we want to stick to that, some amount of dereferencability needs to be required even when a "raw place" is being constructed. But there's also some demand for relaxing this to e.g. makeoffset_of!easier to implement -- there are proposals to instead use a currently-hypotheticalgetelementptr nwfor&raw (*ptr).fieldthat ensures no-overflow but does not say anything about allocation bounds. This would correspond to (raw) place construction only requiring that the place (viewed as a base address and a size) does not overflow the high end of memory, so this is another option that's on the table.- Does
We discussed this in the @rust-lang/lang meeting on 2021-02-09 and we concluded that:
- We want
unsafeto be required here, but that is covered by Unsafe checking skips pointer dereferences in unused places #80059 specifically. - We don't want to settle whether
let _ = *ptris UB or not at this time, it doesn't seem urgent. In other words, it is presently considered UB, and we're ok with that, but we would also definitely consider changing that in the future.
I'm going to remove nomination as there isn't anything urgent to solve at this time.
- We want
We don't want to settle whether let _ = *ptr is UB or not at this time, it doesn't seem urgent. In other words, it is presently considered UB, and we're ok with that,
FWIW, Miri cannot detect this UB since it is not represented in the MIR.
In truth, my opinion is that
let _ = *ptrshould not be UB, regardless of the type ofptr, but it should be unsafe ifptris a raw pointer.It seems that the THIR unsafety checker now disallows (while the MIR checker allows) dereferencing pointers to wildcards:
fn foo(ptr: *const bool) { let _ = *ptr; }
Reacted by Ralf Jung and tema3210This code compiles:
This does not compile any more. I think @cjgillot fixed it? So the issue can be closed if we have a test.
In truth, my opinion is that let _ = *ptr should not be UB, regardless of the type of ptr, but it should be unsafe if ptr is a raw pointer.
That is indeed the semantics we are going for. For
boolandenum Void {}, this is already the case. For!it is not but that's a bug: #117288.
This code compiles:
The MIR is empty, i.e., no ptr deref happens.
But this does not:
The MIR is
unreachable;, i.e., the ptr deref conceptually somehow did actually happen.That is a very strange inconsistency -- the
!type is just yet another type, why does it behave differently here?Curiously, this does not yield any
unreachable: