First, pointers are allowed to point to objects at unaligned addresses, and you can read / write to those addresses using the
_unaligned pointer methods. So, in general, you cannot assume that a pointer is going to point to an aligned address. Only if you know where the pointers come from, you might be able to assume that they are properly aligned.
Others have commented that there are “non-zero” optimizations guaranteed by Rust that prevent changes to this. There is however a subtle difference in the naming of the wrappers that support these optimizations, the ones for integers is called
NonZeroU..., while the one for pointers is called
The truth is that the null pointer bit pattern is not guaranteed by Rust. This might be explicitly guaranteed or not guranteed in the first RFC from the Unsafe Code Guidelines WG, but the WG has not started discussing this issue yet - that should happen early 2019.
Having said this, currently, the only null pointer “value” that LLVM supports is the “all zeros” bit pattern. This is true for both C’s null pointer constant, and for run-time memory addresses that compare equal to this null pointer constant, which are not necessary required to be the all zeros bit-pattern by the C standard.
So while Rust might not guarantee this right now, that
0x0 is true for all platforms that Rust support today, and it might be true for all the platforms that your code runs on and might care about in the future (e.g. your platform requires
atomics support, narrowing down the list). So it is kind of up to you to do a risk assessment about this and make a choice whether you want to rely on this or not.