Should raw pointer deref/projections have to be in-bounds?

[RalfJung]

Currently, when you write addr_of!((*ptr).field), ptr has to be a sufficiently aligned and dereferencable pointer (meaning it has to point to actually allocated memory), with the size/alignment determined by the pointee type.

Formally speaking, this stems from the fact that the * operator, which turns a value (of pointer or reference type) into a place, requires that the pointer be aligned and dereferencable. This is true regardless of the context in which the * operator is used, i.e., regardless of what happens to this place after it has been constructed.

Pragmatically speaking, this reflects the fact that addr_of!((*ptr).field) is lowered to a getelementptr inbounds in LLVM. That said, the rules in the reference go further than what is required for codegen -- they require ptr to be dereferencable for the full size of the type (not just the field), and that even if we do addr_of!(*ptr).

This situation frequently causes confusion, so maybe we want to change it. At least it'd be good to have a central place for discussion and reference, so I created this issue.
Cc @eddyb @joshtriplett @thomcc @Lokathor @cuviper rust-lang/reference#1000
Instance(s) of confusion in practice: rust-lang/rust#93459 (comment)

So, what could we do? Let me collect some proposals that have come up.

Remove restriction from * entirely

The most radical option is to entirely remove the clause which imposes a rule on *, and instead just require that when a place is actually read from (via move/copy) or stored to (via =), then it has to be sufficiently aligned and dereferencable as determined by the type of the place. (We currently do not need such a rule, since as an invariant all places that are constructed are aligned and dereferencable.)

This means we have to remove inbounds from getelementptr in place projection lowering when the "source" of this place projection is a raw pointer. We can still add inbounds for references or other places (locals/statics) since we know those to be dereferencable for other reasons (except for this twist). (We can not add it in cases like &(*ptr).field since ptr might be e.g. 4 bytes before the beginning of the allocation and .field offsets the ptr by 4.)

This has the potential of making LLVM alias analysis and other optimizations less effective. In particular, getelementptr might not just go out-of-bounds, it would even be allowed to overflow, so there are some tricks LLVM might not be able to pull any more.

It is certainly my favorite option, because it maximally reduces the amount of UB -- the remaining rule (about actual loads/stores) is pretty much unavoidable and typically expected by programmers.

Still prevent overflows

We could also say that *ptr on a raw pointer is UB if adding size_of_val_raw(ptr) to ptr would overflow, but allocation bounds do not matter. This would let us emit a hypothetical getelementptr nowrap, if LLVM were to add support for such a flag in the future. I doubt this is any less surprising than our current rules, TBH, but it is less likely to be violated by the typical kind of code people write. It is also more complicated, since we still have to explicitly add the rule which says that loading from and storing to a place requires it to be dereferencable and aligned.

Check inbounds on place projection

If we want to keep codegen unchanged, we could still relax our rules: we could allow addr_of!(*ptr), and we could make it so that addr_of!((*ptr).field) only needs to be inbounds for the actual offset that is performed.

For example, on top of the "remove restrictions" proposal, we could have an extra rule for each place projection which says that this projection needs to be in-bounds.

This has the advantage of keeping our current codegen and quite obviously aligning with the intuition many people seem to have for place projections. It also has some disadvantages though:

• addr_of!((*ptr).field) continues to be UB if ptr is entirely dangling, so e.g. people wanting to write offset_of-style code still have to navigate around a footgun.
• Our rules become more complicated. (Basically, we would replace one bullet in the "Behavior considered undefined" list by two bullets.)

Magic?

There's also the option (which I'm aware you aren't a fan of) of allowing addr_of!((*p).field) to violate the inbounds rule but still requiring &(*ptr).field to uphold it.

#319 (comment)

New syntax

What you really just want to be able to really ergonomically talk about field offsets.

#319 (comment)

[thomcc]

There's also the option (which I'm aware you aren't a fan of) of allowing addr_of!((*p).field) to violate the inbounds rule but still requiring &(*ptr).field to uphold it.

For better or worse, I think most peoples intuition is that addr_of! is somewhat magic. The reasons for this are numerous, but aside from it being a macro (and macros often being somewhat magic), "places" are not a first class concept in the language and thus most rust programmers who are not compiler engineers or have experience in this area do not think in terms of them, or are even aware they exist.

(I think loosing inbounds on raw pointers everywhere would probably be unfortunate (it's hard to say), but I think loosing it just on addr_of! probably is not a big deal -- it may disallow folding the address calculation into the load, but in practice that's not as a big deal on modern machines. My bigger concern is around this possibly being applied more broadly)

[hkratz]

I am wondering why dereferencing of dirent * does not seem to cause problems in C where de->d_name is also compiled down to getelementptr inbounds- Godbolt. I don't think I have ever seen C code that avoids dereferencing it. In the POSIX readdir sample they definitely do not.

[thomcc]

C does the equivalent of option 3 there.

[RalfJung]

aside from it being a macro (and macros often being somewhat magic)

That is IMO a bad argument -- the only reason it is a macro is that we have not found a nice syntax we wanted to commit to. And certainly macros are less magic than "built-in syntax".

"places" are not a first class concept in the language and thus most rust programmers who are not compiler engineers or have experience in this area do not think in terms of them, or are even aware they exist.

In C, I hear programmers talk about lvalues quite a lot. So I think that similarly, in Rust, programmers are generally aware of the concept of a place. I think the rest can be solved with better documentation and teaching -- IMO most explanations of these concepts and how they affect program execution are rather bad, since they don't actually follow the syntactic structure of the program.

There's also the option (which I'm aware you aren't a fan of) of allowing addr_of!((*p).field) to violate the inbounds rule but still requiring &(*ptr).field to uphold it.

The question is how to even systematically specify the language (e.g. in a way that can be implemented in Miri) to achieve this. I think we would need to basically distinguish safe from unsafe places and then, conceptually, use a form of type inference so that at the *p, we know which kind of place is required.

I don't think that is a good idea. If people think addr_of is magic, the answer should be better documentation and teaching, not doubling down on the magic. I don't think we can expect people to reliably write correct unsafe code if they treat a core operator in their code as magic.

[eddyb]

One reason I prefer the first option is because it allows us to make this kind of code safe (as in, not requiring the unsafe keyword) in the future:

addr_of!((*ptr::null::<Struct>()).field)

Whether or not that's a good way to implement offset_of! is another matter, but removing the need for unsafe would signal addr_of!((*ptr).field) can be treated as doing pretty much just this:

(ptr as *const u8).wrapping_add(offset_of!(Struct, field)) as *const FieldType

The unsafe operations, specific to raw pointers and the unsafe places based on them, would then be:

• loading from/storing to an unsafe place
• borrowing an unsafe place as a (safe) reference

I'm not sure if also removing autoderef from (*ptr).field and (*ptr)[idx] (i.e. when ptr is a raw pointer to a type that implements Deref, be it &T, Box<T>, Vec<T>, etc. - though this could also happen in the second half of (*ptr).field[idx] or (*ptr).field1.field2) would be backwards-compatible, but at the very least they would still require unsafe even when used inside addr_of!, and we could lint against them.

I believe the first time such an idea came up was in the context of youngspe/project-uninit#1 - that kind of thing feels like it has to "fight the language" to avoid hazards while doing something on behalf of the user.

[RalfJung]

@eddyb at least with the first option, "unsafe place" here is a concept that only exists for unsafety checking, but not for the actual dynamic behavior of the program or whether code has UB. I like that. :D

I believe the first time such an idea came up was in the context of youngspe/project-uninit#1 - that kind of thing feels like it has to "fight the language" to avoid hazards while doing something on behalf of the user.

I am pretty sure I have seen this discussed (and discussed it myself) way earlier, in 2019 when https://github.com/Gilnaa/memoffset was moved towards "the canonical offset_of in the ecosystem".

[eddyb]

I am pretty sure I have seen this discussed (and discussed it myself) way earlier

Ehm, sorry, my phrasing was ambiguous. For me, specifically, the idea of making some raw-pointer-based field offseting safe (and banning the existing autoderef, or least keeping it unsafe) only came more recently, when seeing this repeat in situations other than offset_of!.

Maybe it's also because for offset_of! it seems reasonable to limit it to one field, whereas project-uninit was allowing whole "field paths" like .a.b.c etc.

[Gankra]

It is my assertion that worrying about the precise semantics of *raw_ptr is treating a symptom and not the actual issue, which is that using * to temporarily enter "path mode" and then only actually specifying what you're talking about at the end with addr_of is a huge confusing mess. What you really just want to be able to really ergonomically talk about field offsets. As a complete strawman syntax that is ignoring parsing concerns:

// Applied to a raw pointer value.

// It's ok if this syntax isn't transactional and we're semantically
// GEP inboundsing to both `field` and `subfield` because subfields
// advance the offset monotonically, and GEP inbounds effectively
// asserts the start and end are in the same allocation and that the
// allocation spans the range between them.
my_ptr~field~subfield.write(val);
*my_ptr~field~subfield += 1;

and

// Applied to a type

// Same as above but caching the offset, possibly as a const.
let subfield_offset = MyType::<T>~field~subfield;
my_ptr.offset(subfield_offset).read()

Once you have this ergonomic syntax that doesn't mess around with places, it's perfectly fine for * to be some enormously powerful assertion about validity because no one will use it like that anymore. At most they'll use it at the very end of a series of offsets, where you do in fact want to assert validity of that final value.

Why won't they use it anymore? Because it is already syntactic salt! (*ptr).field is already super awkward and annoying, if we give them a better alternative (and maybe add lints...) they will happily move off of that horrible syntax!

[Gankra]

Like you can argue all you want about the precise semantics of *raw_ptr but I can't actually teach any of these models to a random person reading the rustonomicon. places/lvalues are deeply compilerese and very confusing when you're trying to very precisely write some hairy unsafe code.

[elichai]

Because the main reason for violating the current rules is for calculating offsets, maybe the right solution is to provide an offset_of macro in the standard library that does exactly that? (and can be implemented via say an intrinsic).
Or a more sophisticated mechanism that allows the user to get the full layout of a type.

That might be enough to allow the current rules to stay as is (as there's no really any reason that I know of to use an invalid pointer other than calculating offsets)

[thomcc]

I don't think the case in rust-lang/rust#93459 would be solved by an offset_of macro, I think it's a broader issue than just offset_of (although that is a component).

[RalfJung]

places/lvalues are deeply compilerese and very confusing when you're trying to very precisely write some hairy unsafe code.

I am not convinced that is true. I was confused by places for a long time but I think I have reached "place enlightenment" some time in 2018 and I think this is something that can be shared -- none of the explanations for this that I saw out there were satisfying, including the one they gave me at university in my first semester.

Or maybe I am just delirious and stared into the sun too long, not sure. I certainly should actually write such a "comprehensible explanation of places" before making such big claims, which I haven't done yet, so maybe it is harder than I think. But I also think if places, which are a rather fundamental concept to Rust, are so hard to explain, then we have bigger problems.

[Gankra]

Places are like autoderef/autoref. You can and must specify them somewhere but no one using rust actually needs to understand them really. It's magic that the compiler does to make your code work, and it's fine that it's magic because the borrowchecker will catch anything that goes wrong (in my experience).

But we don't do autoref/autoderef for raw pointers because in that context wacky-wild-magic semantics are terrifying and not something we can help you use correctly. I regard places as much the same thing.

Now you can't completely eliminate places, but they should definitely be minimized. Most unsafe code has no need to ever actually use places, and just needs to offset and read/write. Code that does want to use places generally only really cares about applying them to the leaf of the access (what my strawman does) and not be the root of the access (what the current system does).

---

Aside:

Arguably you also want a postfix deref operator but once you are restricting the place to a leaf, you hardly need anything better than fn manual_deref_mut(self) -> &mut T on raw pointers. That specific API probably runs afoul of the carveouts for (*ptr).int_field = 3 being ok even if int_field is uninitialized. But at this point you want to just unconditionally do this anyway:

ptr~field1.write(1);
ptr~field2.write(true);
ptr~field3.write(my_struct);

Because it's more ergonomic and much more advisable because it's mindlessly correct compared to:

*ptr~field1 = 1;               // I am very clever
*ptr~field2 = true;            // and know this is safe
ptr~field3.write(my_struct);   // but carefully initialize this part with a dtor

---

I really want to be able to tell unsafe rust programmers:

"Here's this totally braindead and mindlessly correct way to do everything, and it's also the most ergonomic way to do it, so you'll want to do it anyway. (And now here's where you can be a clever smartass if you insist...)"

[RalfJung]

I really want to be able to tell unsafe rust programmers:

"Here's this totally braindead and mindlessly correct way to do everything, and it's also the most ergonomic way to do it, so you'll want to do it anyway.

Fully agreed on that part. :)