size_t-to-int vulnerability in Linux’s filesystem layer

Re:size_t-to-int vulnerability in Linux’s filesystem layer by pornel on Tuesday July 20, 2021 @06:43PM (#27900234)

Even worse, there are platforms with >=128-bit pointers but 64-bit address space. Rust has chosen usize to be uintptr_t rather than size_t, even though it mostly uses it as if it was size_t. A ton of code is going to subtly break when these two sizes ever differ. Rust is likely already doomed on >64-bit platforms, and is going to be forced to invent its own version of a LLP64 workaround.

[ Parent | on HN ]

Re:size_t-to-int vulnerability in Linux’s filesystem layer by TheCycoONE on Tuesday July 20, 2021 @08:50PM (#27901043)

Sorry, I'm not sure how this is a problem. On segmented architectures size_t is smaller than uintptr_t, but that just means there needs to be an allocation limit < usize::max_value.

It would have cause more bugs if they defined it the other way and people used usize to store addresses.

[ Parent | on HN ]

Re:size_t-to-int vulnerability in Linux’s filesystem layer by dezgeg on Wednesday July 21, 2021 @04:43PM (#27911908)

"Fortunately" there will be bigger problems than Rust on 128-bit machines - lots of UAPI structures in the Linux kernel have pointer size hardcoded to 64 bits.

[ Parent | on HN ]