From a certain angle it would seem size_t and ptrdiff_t are meant to roughly correspond to array subscript use cases. Therefore it's not unheard of for them to not be as wide as a pointer. intptr_t is for that.
In your link they have examples where size_t and ptrdiff_t are 16 bits. Obviously this is absurd on today's machines. But you can imagine a machine where array subscript is most convenient at 16 bits and total addressable space is larger (16 bit x86 comes to mind). By the same token I don't think it would be too weird to have a 32 bit size_t on a 64 bit architecture. It would just make memcpy et al more annoying when your allocations are large.
Anyway the quotation from your link:
> The types used for size_t and ptrdiff_t should not have an integer conversion rank greater than that of signed long int unless the implementation supports objects large enough to make this necessary.
I guess if longs are 32bit and you can have a 4g allocation this pretty well follows the spirit here.
In your link they have examples where size_t and ptrdiff_t are 16 bits. Obviously this is absurd on today's machines. But you can imagine a machine where array subscript is most convenient at 16 bits and total addressable space is larger (16 bit x86 comes to mind). By the same token I don't think it would be too weird to have a 32 bit size_t on a 64 bit architecture. It would just make memcpy et al more annoying when your allocations are large.
Anyway the quotation from your link:
> The types used for size_t and ptrdiff_t should not have an integer conversion rank greater than that of signed long int unless the implementation supports objects large enough to make this necessary.
I guess if longs are 32bit and you can have a 4g allocation this pretty well follows the spirit here.