4 ms·
> Let’s start with Rust, which offers the usize type, defining it as “The pointer-sized unsigned integer type. The size of this primitive is how many bytes it t
by nightpool 5y ago
> Let’s start with Rust, which offers the usize type, defining it as “The pointer-sized unsigned integer type. The size of this primitive is how many bytes it takes to reference any location in memory.” That definition is based on the assumption that a machine’s address and data widths are the same
Is this true? I don't know the history here, but just from reading that definition, it seems like `usize` is tied only to the address width. Where does the data width come in?
- gautamcgoel 5y agoYeah I didn't understand that part either. The quote doesn't mention data width at all...
- magicalhippo 5y agoI might be wrong but what came to mind was segmented memory, ie like 8086 where registers are 16bit but (far) pointers are 16:16 (ignoring the quirk with overlapping segments).
- moring 5y agoThat would make usize a 32-bit integer, regardless of the data width. It does make other hidden assumptions though, such as that there is a single "memory" that is uniquely identified by a usize value, regardless of the way it is accessed. For x86, for example, the same address could either refer to a location in memory or to a location in an I/O device, depending on whether in/out instructions or "normal" instructions were used.
- magicalhippo 5y ago> That would make usize a 32-bit integer, regardless of the data width. Doh, long day at work, misinterpreted "data width".
- fanf2 5y agoRust’s usize does the jobs of both uintptr_t (a pointer-width type) and size_t (a data-width type)
- Diggsey 5y agosize_t is just a type that's large enough to hold the largest possible object. It doesn't necessarily relate to the register size... This means that `uintptr_t` must be at least as large as `size_t`, and so Rust's usage of `usize` for both is not problematic.