Specify that int and uint are at least 32 bits on every CPU architecture

[1fish2]

Guaranteeing that int and uint are always at least 32 bits fixes the class of bugs and security holes that worries me most in #9940

Scenario:

• Programmers use int and uint in library code and sample code explicitly, or by thinking of them as the "default integer types," or via integer type inference. See consider removing the fallback to int for integer inference #6023
• When reusing that code on a 16-bit embedded processor (e.g. in robotics and IoT devices -- Rust would be very compelling for such applications), it has bugs when int and uint overflow in 16 bits, which is not difficult.

I encountered this problem when programming in C++ on Palm OS. (It's a 16-bit OS even on devices that used a 32-bit ARM to emulate the 68000.)

Of course there are alternate solutions.

[alexchandel]

No, I like that int and uint refer to the native integer type of the architecture. Besides, in embedded platforms, you should always use fixed-width integer types. Since this would be a language change, it would have to go through the RFC process.

[thestinger]

The int and uint types are defined as pointer size integers, not "native" size. The x32 ABI has 32-bit pointers and 64-bit general purpose registers, and int/uint would be 32-bit.

[alexchandel]

My mistake. Fortunately the RFC probably wouldn't affect x32. Maybe int should be the size of the integer register? I mean, safe Rust doesn't allow the casting of pointers to ints anyway (e.g. &T as int). Maybe, there should be two unsized types: int and intptr (and their unsigned counterparts uint and uintptr). I disliked the RFC replacing int with intptr, but the separation of integer-register-sized and pointer-sized ints could be a meaningful feature, especially for low-level code.

[thestinger]

A platform can provide any number of registers with varying sizes. Using 32-bit integers on x86_64 / ARM64 rather than 64-bit ones will be faster. Using the largest type implemented in hardware may make sense for cases like a big integer implementation, but it's fine to leave that as a job for libraries. The int and uint types need to be built-in because they're used by the language itself.

[alexchandel]

Why would 32-bit integers be faster? x86_64 has instructions for load qwords in one step, and for arithmetic.

[thestinger]

Instruction count doesn't determine performance. The 32-bit integers are smaller (more data in cache), the instructions are faster and the vector instructions can deal with twice as many at a time.

[1fish2]

Correct me if I'm wrong: Rust defines int and uint as pointer-sized integers, uses them for array indexing (since uint spans exactly the address space), and any other use of them is a mistake and will create library code with bugs on CPUs with 16-bit pointers.

These may not be the most efficient integer types (see @thestinger 's 64-bit example and my 16-bit example) and they shouldn't be used "by default" since the results are non-portable.

#9940 proposed to fix those two problems by renaming int and uint to intptr/uintptr for clarity and intentional awkwardness.

This issue proposes to make int and uint not cause bugs on CPUs with 16-bit pointers.

[thestinger]

Closing in favour of rust-lang/rfcs#161. It doesn't belong as an issue on the tracker anymore.