5 ms·

into() does not work from size. It's rather frustrating in practice. https://stackoverflow.com/questions/62832438/why-is-rusts-usize-to-u128-conversion-consider

into() does not work from size. It's rather frustrating in practice. https://stackoverflow.com/questions/62832438/why-is-rusts-usize-to-u128-conversion-considered-failable https://stackoverflow.com/questions/62832438/why-is-rusts-us...

masklinn 5y ago
> It's rather frustrating in practice. All explicit conversions, more so fallible, are "frustrating in practice" especially when coming from a language without those foibles. But given the semantics of usize/isize, it is perfectly reasonable, nay, a good thing, that they're considered neither widenings nor narrowings of other numeric types.
- ridiculous_fish 5y ago
  usize should be Into<u64> iff usize is <= 64 bit. usize is already on that hook: `0x100000000usize` will fail to compile in 32 bit, so you already risk compile errors when switching archs. As it is I'm just writing `as u64` which is clearly worse.
eloff 5y ago
Yeah, that is frustrating since there are no platforms where that would fail today, and it's hard to imagine why we would ever want one with 256bit pointers. We don't even use full 64bit pointers today on x64.
- mgraczyk 5y ago
  The Ethereum virtual machine addresses it's storage with 256 bits, so there's one wild example. Although in this case you'd probably not want to use usize directly to represent storage.
  - eloff 5y ago
    I'm not familiar with the Ethereum virtual machine, are these really memory pointers? Surely it's represented differently?
    - mgraczyk 5y ago
      EVM is a stack machine, and it has durable storage which is addressed using 256 bit "pointers". So you can do something like push x // 256 bit constant LOAD // top of stack now contains storage[x]
- est31 5y ago
  When 16 bit computers went to 32 bit, people probably thought that one wouldn't ever need 64 bit computers either. That being said, by the time 128 bit run out we have probably boiled earths oceans :). You could think of checked memory models where half of the 256 bit address is a 128 bit random key needed to access some allocation, or maybe even a decryption key. Similar things are done with the extra space of x64 as well. Also, 128 bit numbers are still quite uncommon in Rust. Easy conversion of usize to them wouldn't be that useful if conversions of the other number types don't work.
  - a1369209993 5y ago
    > When 16 bit computers went to 32 bit, people probably thought that one wouldn't ever need 64 bit computers either. People have said that about pretty much every memory size in the history of computing. The argument for 64-bit is not "2^64 bytes ought to be enough for anyone"; it's "you couldn't use more than 2^64 bytes even if you wanted to". Writing a full register worth of data every clock cycle at 4GHz works out to 32GB/s. (2^64B / 32GB/s) is just over seventeen years, to fill up a 64-bit address space, assuming you're doing no actual computation. Few computers even work for seventeen years without replacement, much less run single processes continually with no reboots.
- fulafel 5y ago
  Maybe a fat pointer llvm target ala SoftBound running on a machine with 128 bit bare pointers, like as/400.
- pornel 5y ago
  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.
  - TheCycoONE 5y ago
    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.
  - dezgeg 5y ago
    "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.

masklinn 5y ago

> It's rather frustrating in practice. All explicit conversions, more so fallible, are "frustrating in practice" especially when coming from a language without those foibles. But given the semantics of usize/isize, it is perfectly reasonable, nay, a good thing, that they're considered neither widenings nor narrowings of other numeric types.

ridiculous_fish 5y ago
usize should be Into<u64> iff usize is <= 64 bit. usize is already on that hook: `0x100000000usize` will fail to compile in 32 bit, so you already risk compile errors when switching archs. As it is I'm just writing `as u64` which is clearly worse.

eloff 5y ago

Yeah, that is frustrating since there are no platforms where that would fail today, and it's hard to imagine why we would ever want one with 256bit pointers. We don't even use full 64bit pointers today on x64.

mgraczyk 5y ago
The Ethereum virtual machine addresses it's storage with 256 bits, so there's one wild example. Although in this case you'd probably not want to use usize directly to represent storage.
- eloff 5y ago
  I'm not familiar with the Ethereum virtual machine, are these really memory pointers? Surely it's represented differently?
  - mgraczyk 5y ago
    EVM is a stack machine, and it has durable storage which is addressed using 256 bit "pointers". So you can do something like push x // 256 bit constant LOAD // top of stack now contains storage[x]
est31 5y ago
When 16 bit computers went to 32 bit, people probably thought that one wouldn't ever need 64 bit computers either. That being said, by the time 128 bit run out we have probably boiled earths oceans :). You could think of checked memory models where half of the 256 bit address is a 128 bit random key needed to access some allocation, or maybe even a decryption key. Similar things are done with the extra space of x64 as well. Also, 128 bit numbers are still quite uncommon in Rust. Easy conversion of usize to them wouldn't be that useful if conversions of the other number types don't work.
- a1369209993 5y ago
  > When 16 bit computers went to 32 bit, people probably thought that one wouldn't ever need 64 bit computers either. People have said that about pretty much every memory size in the history of computing. The argument for 64-bit is not "2^64 bytes ought to be enough for anyone"; it's "you couldn't use more than 2^64 bytes even if you wanted to". Writing a full register worth of data every clock cycle at 4GHz works out to 32GB/s. (2^64B / 32GB/s) is just over seventeen years, to fill up a 64-bit address space, assuming you're doing no actual computation. Few computers even work for seventeen years without replacement, much less run single processes continually with no reboots.
fulafel 5y ago
Maybe a fat pointer llvm target ala SoftBound running on a machine with 128 bit bare pointers, like as/400.
pornel 5y ago
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.
- TheCycoONE 5y ago
  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.
- dezgeg 5y ago
  "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.