Document min pointer width.

[ehuss]

Closes #643.

[ehuss]

If the lang team is not ready to make the min-size commitment, I can easily just remove the addition to numeric.md. I think highlighting that 16 is a valid option to target_pointer_width is a good thing to add regardless.

[joshtriplett]

I don't think we should add this without a very large caveat that it's entirely reasonable for 16-bit pointers to have limited support, and that many libraries may assume that usize is at least 32-bit. 16-bit pointer support is something I'd expect to require explicit care and acknowledgement of in a library crate that supports it, much like no_std support.

From a language point of view, yes, usize and isize are at least 16 bits. But I think there's value in at least a descriptive statement like "Note that many pieces of Rust code may assume that pointers and usize/isize are at least 32-bit and at most 64-bit."

[ehuss]

Thanks for taking a look! I've updated with a note.

[chorman0773]

I'd recommend clarifying whether pointer widths that aren't powers of 2 are permitted. I explicitly mention 24-bit because what I work on deals with pointers that are really 24-bit.

[chorman0773]

Would this allow targets where pointers are really 24-bits, such as the 65816?
Technically speaking, I forcibly extend pointers to 32-bit, but they only have 24 significant bits.

[joshtriplett]

There are two separate questions to answer here, I think.

First, whether pointer size here refers to the "significant bits" or the actual size of a pointer value. I think it refers to the latter, so even if you only have 24 significant bits, if you extend pointers to 32-bit then the pointer size is 32-bit.

But if you don't extend pointers, then that raises an interesting question. I don't see a fundamental reason why (for instance) we couldn't support systems with 80-bit pointers and 80-bit usize, or why it would have to be rounded up to 128-bit, as long as LLVM (or whatever backend we used for the platform) supported those 80-bit values.

If we add mentions of such cases, though, then I think we'd need to change the clarifying note I suggested to say that "Many pieces of Rust code may assume that pointers, usize, and isize are either 32-bit or 64-bit". Because a system with 40-bit or 48-bit or 56-bit pointers would likely run into many of the same difficulties and limited library support as a system with 16-bit or 24-bit or 80-bit or 128-bit pointes.

[chorman0773]

I extend pointer size to a multiple of the alignment, 4-bytes. However I treat the 4th byte as padding, rather than treat it as part of the value.

[ehuss]

The listed values are only intended as examples, not something exhaustive. However, rustc currently only supports 16, 32, and 64. It seems like to me that the language definition does not need to take a stance on anything other than the minimum, at least for now.