Why would hard-coding the ability to access a slice of bytes as ints into the compiler be safer than a well-encapsulated unsafe code abstraction?
We used to implement things like vectors directly in the compiler, but it was a big headache for no gain. Writing actual code is way easier than writing code to generate LLVM IR.
Anyway, there is a commonly-used crate for this: byteorder. Had I written the library, I would have just used that crate. But it's not a big deal either way.
> Why is there an "isize" (a signed quantity) in there?
Because pointer arithmetic is signed.
> The documentation for Rust's "std::ops::BitAnd" doesn't say what the semantics are for signed numbers
Bitwise operations on signed integers are applied to their twos complement representations.
> What would happen on a 32-bit machine if someone allocated a buffer bigger than 2GB?
I actually talked to Lattner about the isize thing a few months back -- according to him it's fine to overflow while doing GEP because llvm shouldn't care if you pass in negative offsets to represent really big positive ones.
Yeah, it just wasn't clear to me (or anyone else I asked) that GEP wasn't "allowed" to strictly interpret signedness and inboundness. LLVM docs, amirite?
We used to implement things like vectors directly in the compiler, but it was a big headache for no gain. Writing actual code is way easier than writing code to generate LLVM IR.
Anyway, there is a commonly-used crate for this: byteorder. Had I written the library, I would have just used that crate. But it's not a big deal either way.
> Why is there an "isize" (a signed quantity) in there?
Because pointer arithmetic is signed.
> The documentation for Rust's "std::ops::BitAnd" doesn't say what the semantics are for signed numbers
Bitwise operations on signed integers are applied to their twos complement representations.
> What would happen on a 32-bit machine if someone allocated a buffer bigger than 2GB?
It would work.
> Exploitable?
No.