To try to clarify: most existing Plan 9 code doesn't worry about the actual type of sizeof or pointer differences. They assume int/long or uint/ulong. It's obvious from this discussion that hardly anyone noticed usize. Since its introduction years ago, grep shows that only kernel code has used usize. size_t is more popular in ANSI C code, but I suspect even there neither size_t nor ptrdiff_t are used everywhere they ought to be. An arbitrary sample (my src directory on Linux) shows 4995 uses of size_t, and only 54 of ptrdiff_t, but perhaps pointer subtraction just isn't that common.
That's why I say that it would be better to make int and uint the same size as uintptr, although it's a bit of a waste, since existing code that needs bigger int values will use another type, but after the change it's easy to have code casually assume 64 bits. One reason 6c doesn't make int and long 64 bits is that it's quite hard to find code (automatically) that assumes they are 32 bits. Hence the drive to use explicit types when it matters. Again, I'll note that erik's manual page doesn't propose or introduce anything new: even allowing for the ill-chosen "typically" and "usually" it is still a fair reflection of the current state, or aims to be. Perhaps the unfortunate qualifications should be in BUGS. On 22 November 2012 11:10, Richard Miller <9f...@hamnavoe.com> wrote: >> usize is indeed the same size as uintptr. >> Instead of either for purely integer values, it would be better to >> make all integers 64 bit > > I hope that was intended as a joke. It's not that long ago I was > writing C for a 16-bit processor (in a smart card). I would hate to > lose the meaning of "int" as "whatever fits in a CPU register". > >
