The page mentioned "a codebase originally written for 32-bit". These codebases are probably quite old, old enough to have been written before stdint.h was a thing.
AFAIK, stdint.h is from 1999, and at least one very popular operating system didn't have it until this decade; of the codebases mentioned, according to Wikipedia for instance both PHP and zlib are from 1995.
Nowadays, I agree: you should use stdint.h (or cstdint for C++) for everything, plus size_t (from stddef.h/cstddef) for array/buffer sizes.
Yes, but that doesn't tell you how big pointers are. One of the big problems comes with assigning a pointer (which is 32 bits) to an integer and back. You can specify that it's a uint32, but that doesn't save you - when pointers go to 64 bits, it still doesn't fit.
While you're right, this does not look like a good coding practice to me. I cannot think of a good example where you have to assign a pointer to an integer and back. Better keep it a pointer, even if it's void*.
Yes, absolutely. If you're trying to put a pointer into an int-ish variable, that's what you should be doing - not any of the int types that have a fixed number of bits.
