many existing C programs (and not just on Plan 9) think long is 32 bits, or don't care. those that do care don't work. for those that don't care, it doesn't matter. it's quite difficult to decide automatically (eg, in a compiler) into which category a program falls. a compiler can't easily detect that a program expected 32 bits only and will malfunction with 64. libflate was full of that, but it wasn't the only one. of course, in time, those can be changed to using u32int (or u64int) to make intentions clear.
by contrast, if long remains 32 bits (thus satisfying most existing programs for integer operations), but pointers are 64 bits, it's easy for a compiler to spot conversion of a pointer to an integer type that is too small, and the plan 9 compilers will do that. there are very few such cases in the plan 9 code, and thanks to the compiler diagnostic, we know exactly where they are and whether they matter, and have converted them to use uintptr. if it's performance you're worried about, for programs that don't care about width, i'd expect 32 bits at least to match performance with 64 bits (if there's a measurable difference). for one thing, cache lines will contain more values, and several will be fetched at once when cache lines are filled.
