Reading methods are not sound w.r.t alignment

[bluss]

The byteorder crate is casting a u8 pointer to for example *const u64 and reading it. This requires that the pointer is well aligned for the new element type, otherwise this is UB.

[BurntSushi]

Could you explain a bit more about the UB? (I'm not familiar with this particular case.)

I take it that asserting the length of a &[u8] is sufficiently long is not enough?

[bluss]

Using * on a raw pointer is reading the value through the pointer.

The pointer must be well aligned for the element type of the memory access.

The typical way to do a possibly unaligned access in a well defined way is like this

https://github.com/rust-lang/rust/blob/9cc430d2cf90a38880e02bb319a5563cbe07a40c/src/libcore/hash/sip.rs#L102-L113

disclaimer: I wrote that code. But that's exactly what for example google's farmhash does in C to do a possibly unaligned load. On a platform where unaligned loads are unproblematic, the compiler generates a regular load. I don't know its performance on other platforms than x86 though, there could be better ways to do it there possibly, but this approach is at least sound.

• http://llvm.org/docs/LangRef.html#pointer-aliasing-rules has a brief mention of alignment
• http://llvm.org/docs/LangRef.html#load-instruction spells out that invalid alignment is UB “Overestimating the alignment results in undefined behavior. ”
• http://doc.rust-lang.org/nightly/reference.html#behavior-considered-undefined
  • Does not spell it out concretely. Depending on definition it may even be a dangling pointer (pointer to invalid target).

[bluss]

If you deref a *const u64, rustc generates a load that assumes that pointer is well aligned. When it is not, that results in the emitted code overestimating the alignment.

I would not even cast a *const u8 that is not well aligned, to another pointer type.

[BurntSushi]

I see, thanks for explaining and pointing to a solution. :-) That makes sense. So switching to copy_overlapping for everything sounds like the answer here.

[DoumanAsh]

This issue appeared because of me occasionally looking into byteorder code and writing my own vehicle for byte operations...
With some help i made simple generic conversions from\to bytes and tried to make it as safe as possible via traits:
In case if you'll find it interesting you can take a look at my repo:
https://github.com/DoumanAsh/lazy-bytes-cast

[BurntSushi]

I found this page to contain the best explanation I've seen so far: https://www.securecoding.cert.org/confluence/display/c/EXP36-C.+Do+not+cast+pointers+into+more+strictly+aligned+pointer+types

[BurntSushi]

Fixed in #48.