4 ms·
This is why you should use stdint.h as much as possible, then you know exactly what kind of integers you're dealing with.
by Kenji 10y ago
This is why you should use stdint.h as much as possible, then you know exactly what kind of integers you're dealing with.
- boxerab 10y agoamen!
- cesarb 10y agoThe 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.
- AnimalMuppet 10y agoYes, 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.
- chrisballinger 10y agoWhat about uintptr_t?
- AnimalMuppet 10y agoYes, 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.
- Kenji 10y agoWhile 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*.