Note infinite-precision in std::ptr Allocation docs

[iximeow]

This was noted off-handedly in #116675 where this section was reworked. It seems worthwhile to note explicitly that an allocation's base and size are not "usize" or "isize" but infinitely-wide types where <= usize::MAX cannot be trivially assumed.

I got here trying to figure out if/why with_exposed_provenance::<(u8, u8)>(usize::MAX) returns an invalid *const T. either base + size <= usize::MAX is trivially true, or there's an assumption of wider-than-usize arithmetic and the answer is "it's invalid". seems like the latter, thank goodness! this was discussed in a few places in #116675 (this other comment for example) but ended up left to a careful reader in the landed docs.

[rustbot]

r? @Mark-Simulacrum

rustbot has assigned @Mark-Simulacrum.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: @scottmcm, libs
• @scottmcm, libs expanded to 7 candidates
• Random selection from Mark-Simulacrum, jhpratt, scottmcm

[iximeow]

thank u rustbot

[saethlin]

I don't know what you mean by infinite-precision. I'm not sure we've ever used that terminology with regard to provenance, is there another way to express what you mean?

If someone does call with_exposed_provenance(usize::MAX), since there cannot be any allocations at usize::MAX, the assumption is that if the pointer is used later in a way that requires provenance, that it will have its address moved into range using with_addr/map_addr/wrapping_offset.

[iximeow]

this is more about "can an allocation wrap across the end of the address space" than anything about provenance; I only mention with_exposed_provenance because the only way I could even try coming up with an argument about such an allocation would be to say "outside of Rust I know there is an allocation at 0xff..fff000..u64::MAX and 0..0xfff" and the Ralf in my head would be very irritated at just casting numbers to pointers.

infinite-precision refers to base and size in the docs - if they are usize types then base + size <= usize::MAX is always true and according to the rules laid out in std::ptr Allocation then why couldn't an allocation start at usize::MAX - 1, be four bytes long, and wrap to the start of address space? either way I hope this is more obvious from the diff alone than when it's muddied with my PR description?

since there cannot be any allocations at usize::MAX,

couldn't there be a ZST there? (though also since base + size <= usize::MAX, that implies that an allocation cannot happen to have a byte at usize::MAX..?)

[saethlin]

I see. I think it would be less confusing to add a note that none of the arithmetic wraps. At least it would have been easier for my brain because that's a term we already use in this space.

[iximeow]

I've adjusted the wording a bit differently, any time I tried to describe it as non-wrapping arithmetic it felt a bit hamfisted.. but in the "As a consequence ..." section we've already described the idea that sums do not wrap the address space. so I think it reads better to pull that up to talk about base + size, expand on the idea there, and repeat that same phrasing below for base + o. at least to me I think this reads better than appealing to infinite-precision arithmetic too?

does this read better to you as well?