Some questions around what is UB and what is defined when using raw pointers

[elichai]

Hi,
Read quite a lot of the information out there and I still have a bunch of open questions about pointers, answering them will help me but I also think that it will be good to add to the docs for other people.

This list isn't exhaustive and I'll try to add stuff I see and don't know the answer to:

1. Passing a pointer to a const variable. -> Is fine but may result in different pointers to the same variable (See Some questions around what is UB and what is defined when using raw pointers #205 (comment))
2. Mutating a const variable through raw pointer casting. -> Not allowed. (See Some questions around what is UB and what is defined when using raw pointers #205 (comment))
3. Casting a pointer to usize and back.
4. Checking alignment via modulo over ptr as usize. (related to 3) (less relevant now that we have align_offset but people still do it in the wild).

[elichai]

I think 2 can fall as UB under:

In general, transmuting an &T type into an &mut T is considered undefined behavior.

This is a quote from: the docs of UnsafeCell. and should also be mentioned here in my opinion.

[bjorn3]

Mutating a const variable through raw pointer casting.

Thats simply imposible, consts dont have any address, when you take &MY_CONST a new promoted will be created. That promoted will be in read only memory.

[elichai]

@bjorn3 you're talking in a mindset of the rustc low level.
In practice this can happen on purpose or on accident and will currently cause a Segmentation Fault https://play.rust-lang.org/?gist=99b3e1414761fb27a176d960ac56baa0 (while I get that probably it doesn't try to modify the const, but probably do something else).

[gnzlbg]

@elichai you did not understand what @bjorn3 mentioned: that code does not create a pointer to a const (EDIT: re-read @bjorn3 explanation, they explained it properly).

[elichai]

re-read it again. and what you're saying is that every call to &CONST creates a copy of that const in read only memory?
meaning that giving a raw pointer to that const is fine(and (&MY_CONST as *const _) != (&MY_CONST as *const _)) but mutating it will probably crash the program(because it's read only memory).
Did I understand correctly now?

[bjorn3]

and what you're saying is that every call to &CONST creates a copy of that const in read only memory?

Conceptually, yes, but within one object file it is deduplicated, but copies can exist in different crates.

meaning that giving a raw pointer to that const is fine

Yes

and (&MY_CONST as *const _) != (&MY_CONST as *const _)

As said above within one object file it is likely equal, but between different crates it isnt.

but mutating it will probably crash the program(because it's read only memory).

Yes

[bjorn3]

Casting a pointer to usize and back.

I believe it is always allowed, but impedes some optimizations

Checking alignment via modulo over ptr as usize. (related to 3) (less relevant now that we have align_offset but people still do it in the wild).

Allowed, but miri used to not support ptr<->int casts, so align_offset was invented.

[gnzlbg]

and what you're saying is that every call to &CONST creates a copy of that const in read only memory?

Conceptually, yes, but within one object file it is deduplicated, but copies can exist in different crates.

That's more an optimization that is sound for programs that don't exhibit UB, than the semantics of the language it self.

In the abstract machine, using a CONST creates a new temporary allocation and makes a bitwise copy of the CONST to this allocation. That's all there is to it.

When you write &CONST you are creating a pointer to that allocation, and that pointer is the only way to access the allocation. If the type of the CONST is Freeze there is no way for a Rust program to modify the contents of the allocation from that pointer or pointers derived from it. So we know that the allocation is read-only, and therefore it is correct to put them in the rodata segment of the binary. This is the optimization @bjorn3 mentioned.

However, if you create a &mut T to the temporary, then writing to it is perfectly fine. If you create a &T and T: !Freeze, then writing to it is fine as well . These are just normal Rust semantics at work, there is nothing specific to consts here. These same rules apply to any allocation in the program.

and (&MY_CONST as *const _) != (&MY_CONST as *const _)

Since the allocation is a local private temporary, that's like writing this:

let x = 3;
let y = 3;
assert!(&x as *const _ as usize != &y as *const _ as usize);

We do not provide any guarantees about what the addresses of x and y are. You can compare their addresses - that's not UB - but there are no guarantees about what the outcome of that assert is.

---

Casting a pointer to usize and back.

This is not UB.

---

Checking alignment via modulo over ptr as usize.

This is not UB either. At most is a logic bug, and sometimes, it even works correctly.

[elichai]

@gnzlbg Thank you. I finally think I understand consts in rust properly :)
For a sec it didn't make sense to me how &mut MY_CONST is even allowed but I get it now.
consts get copied and become a temporary on every invocation.
Thanks for clearing that up :).

This is not UB.
Assumed that. but good to know that's defined.

This is not UB either. At most is a logic bug, and sometimes, it even works correctly.

So that's not a proper way to check alignment? (by looking at the implementation of offset_align I assumed it's not really the right way to do this heh)

[gnzlbg]

So that's not a proper way to check alignment? (by looking at the implementation of offset_align I assumed it's not really the right way to do this heh)

That's how I understand it. It is not a good way to check alignment, but it is not UB per se. If that returns some incorrect result, your program might or might not do something later that is UB.

[RalfJung]

I think 4 can fall as UB under:

In general, transmuting an &T type into an &mut T is considered undefined behavior.

4 is about alignment. What am I missing?

---

Mutating a const variable through raw pointer casting. -> Not allowed.

The conclusion was actually more like "not syntactically possible".
It's like asking "what is the behavior of adding a unicorn to 3?". It's not that Rust disallows it, is that this is not a question that is even well-formed in the context of Rust.

Mutating read-only memory through raw ptr casting is UB, and the reference says so:

Mutating immutable data. All data inside a const item is immutable. Moreover, all data reached through a shared reference or data owned by an immutable binding is immutable, unless that data is contained within an UnsafeCell.

---

Casting a pointer to usize and back.

That's not a question. But know that int-ptr-casts are very poorly understood in C and LLVM, and Rust inherits this. But given that in Rust you can only cast usize with raw pointers, nothing can go wrong. These are even safe operations so I wonder why you might even think they are UB?

---

Checking alignment via modulo over ptr as usize. (related to 3)

Indeed that's the only way to actually check alignment. align_offset is not for checking alignment, it is for aligning things.

[gnzlbg]

All data inside a const item is immutable.

That makes it sound like const items contain data, but I don't think this is the case, e.g., 3 does not contain any data.

[elichai]

4 is about alignment. What am I missing?

Sorry fixed. I meant 2.

The conclusion was actually more like "not syntactically possible".

I still think it's worth explaining because people who aren't familiar with how rust operates consts (like me before reading this thread :) ) it sounds confusing to tell them that something "isn't possible" when they can easily do &A as *const _ as *mut _ so I think it's worth explaining why it's not syntactically possible.

That's not a question. But know that int-ptr-casts are very poorly understood in C and LLVM, and Rust inherits this. But given that in Rust you can only cast usize with raw pointers, nothing can go wrong. These are even safe operations so I wonder why you might even think they are UB?

If I wasn't clear enough I meant will it be UB when dereferencing. Can int-ptr-cast change the pointer in some edge case or is this completely fine to do and then dereference(assuming the original ptr was fine to dereference).

Indeed that's the only way to actually check alignment. align_offset is not for checking alignment, it is for aligning things.

What's wrong with assert!(ptr.align_offset(8)==0)?. are you saying it's better to do the modulo?

[comex]

let x = 3;
let y = 3;
assert!(&x as *const _ as usize != &y as *const _ as usize);

We do not provide any guarantees about what the addresses of x and y are. You can compare their addresses - that's not UB - but there are no guarantees about what the outcome of that assert is.

Interesting. That would be weaker semantics than C, which does guarantee that different variables have distinct addresses (including locals), as long as those variables are all in scope. Has this been discussed before?