Document that isize/usize are at least 16-bit wide on all platforms we currently support

[gnzlbg]

This is something that we already document, but was not explicitly spelled out.

cc @gankro

[gnzlbg]

TL;DR: this documents that for all practical purposes isize/usize are at least 16-bit wide, but leaves the door open for 8-bit platform support. I think that any stronger wording would make supporting those platforms illegal, and I don't know if this is something we want. I don't see what that would buy us.

---

So I started guaranteeing that isize/usize are at least 16-bit wide, and falled back to just documenting that, for all platforms we currently support, this is the case.

The current guarantee says that the layout of isize/usize matches that of intptr_t/uintptr_t, so if those are 16-bit wide, which they are on all platforms that we currently support, then this holds for isize/usize as well.

However, this also means that if our platform doesn't have a C platform, or a C standard conforming platform, not much about the layout of isize/usize is guaranteed. This could be useful, if somebody wanted to ever support 8-bit platforms. C does not support them, so Rust could add support for them in whatever way it sees fit, and still remain C-compatible in 16-bit platforms and up.

There is the "issue" of libcore providing unconditional impls of From<i16>/From<u16> for isize/usize. These impls are correct for all platforms we currently support, so that's fine. An 8-bit platform can just cfg these impls out. Code that relies on them would just fail to compile, and AFAICT, that's ok.

[comex]

Note that even "8-bit" CPUs mostly have 16-bit address spaces, even though that means that a memory address cannot fit into a single register. For example, in the Intel 8008 and derivatives, addresses are specified using two 8-bit registers 'H' and 'L' (high and low), which the CPU concatenates to form a 16-bit address.

[gnzlbg]

Good point. We can drop the last commit, and make this a real guarantee. I'm not sue what the full implications of that are, or whether we are already making this guarantee, so I changed that to at least document current behavior. But if we can guarantee this without draw-backs, we should.

8-bit pointers sound like a extremely limiting concept to me. If one is restricted by that, writing code for such a target probably won't look like Rust at all.

[briansmith]

This doesn't belong in the unsafe code guidelines. It belongs in the core language documentation. In particular, it affects whether or not we can implement From<u16> for usize which doesn't have anything to do with unsafe code.

[gnzlbg]

It belongs in the core language documentation.

@briansmith feel free to open a PR to the core language documentation to document this there as well. although I'm not sure where you could put this there. Probably in the usize/isize docs, the reference part talking about integers, and the nomicon part talking about integers.

[RalfJung]

@briansmith note that this here is just a statement about "all platforms we support right now". It doesn't exclude the possibility of adding support for other platforms in the future; that is beyond the WG's power.

[RalfJung]

LGTM.