No code should cast a pointer to a `long`, ever. Trying to excuse it it with "we don't support 32-bit" is deeply wrong.
EDIT: Apparently this position is unpopular. I am curious why people feel differently.
Hell I still try to make sure stuff works on both big and little endian.
It is also likely that general purpose CPUs will use 64-bit integer registers and address spaces for the rest of our lifetimes. Computing has already (for the most part) converged on a standard: Von Neumann architecture, 8-bit bytes, two's complement integers, IEEE floating point, little-endian. The number of oddballs has dramatically decreased over the past few decades and the non-conforming CPUs manufactured every year are already a rounding error.
FWIW If a transition is ever made to 128-bit that will be the last. There aren't 128-bits worth of atoms in the visible universe.
(Imagine installing 2^256 sound cards in a system ...)
It's deeply wrong as an excuse but for a different reason: casting a pointer to long also works on 32-bit. The only mainstream architecture in which it doesn't work is 64-bit Windows.
More generally, I disagree with absolutist takes on programming. There's no right or wrong in programming. There's just requirements and choices.
Also, you can't reasonably remove all undefined behaviour. In C++ you basically can't do file IO without undefined behaviour.
“ The behavior is undefined if the calls to functions in this library introduce a file system race, that is, when multiple threads, processes, or computers interleave access and modification to the same object in a file system.”
No, that's not a portable behaviour but I can see that it's valid if you're targeting Linux.
uintptr_t is more polite, though.