it's also one of those things where like, basically *every* pointer offset llvm ever messes with is `inbounds` so random shit might just require it because it makes things easier and no one cares about non-inbounds codegen
Conversation
Replying to
it's *unlikely* but not *impossible* to have a 2^31+2-byte alloc on a 32-bit architecture, and i'm computing the end pointer ahead of time
2
2
Replying to
oh yeah i, yep -- i am now remembering spending way too much time worrying about overflowing pointer shit in the stdlib for exactly 32-bit and shit like PAE
1
1
but yeah llvm *extremely* pervasively assumes pointer offsets fit into an isize without overflow so it's generally "safe" to assume no one ever creates such an allocation because it would break so extremely bad -- certainly the rust stdlib avoids ever generating such an alloc
1
3
I had to add wording to Rust's language specification forbidding objects larger than isize::MAX (PTRDIFF_MAX in C) because anything larger is incredibly broken in either LLVM or GCC. It's the only realistic way to enforce safety.
See gcc.gnu.org/bugzilla/show_ for a GCC example.
1
1
Also, too hard to avoid doing x-y everywhere which would be undefined even with a looser interpretation of the standard not assuming this is handled by the runtime.
Runtime must not put allocation at 0 or size::MAX and needs to enforce isize::MAX size. GCC/LLVM both assume this.
1
This isn't an issue on most platforms for either pure 32-bit or 64-bit architectures. It's a real world issue for 32-bit processes on 64-bit. musl, Bionic, jemalloc, etc. prevent you creating an object larger than PTRDIFF_MAX. glibc does not, so it's broken with GCC and LLVM.