Well, yes, I'd like to do that, but programmers make mistakes and it isn't easy to test.

Also, you can't reasonably remove all undefined behaviour. In C++ you basically can't do file IO without undefined behaviour.

As a fellow UB nitpicker, I'd like to hear more about your favorite UB triggers. E.g. in the space of file IO.

The C++ filesystem section contains the following, which basically means you can’t do safe IO when other programs are running in the same computer:

“ 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.”

I'm not sure that means much, since that's true of literally every language that does file I/O.

On GCC , as far as I know, pointers will always cast to long and back ok. I'd expect the same from clang.

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.

I agree with you, we have appropriate types now, so we don't need to use long anymore - long also has different assumptions in Windows x64 builds vs equivalent regular Linux x64 (see also LLP64 vs LP64 vs ILP64)

This is simply correct and I see no excuse for objecting.

Hell I still try to make sure stuff works on both big and little endian.

> 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.

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.

Sure, but just because something works doesn't mean you should do it. Better types have been around for what 25 years now?

Does it matter to remove portability to platforms we don't care about any more? It's a question with no objectively/universally right or wrong answer. The obvious counterpoint I'd mention is big endian: is it worth fixing your endianness bugs? Or is it ok to assume little endian since the vast (VAST) majority of software does not care about the very few remaining big endian platforms? 32-bit could become a similar situation. It happened with 16-bit, right? Nobody today cares whether their modern code is portable to 16-bit machines.

More generally, I disagree with absolutist takes on programming. There's no right or wrong in programming. There's just requirements and choices.

Casting a pointer to long is incorrect on any LLP64 platform, which includes all modern versions of Windows.

No matter how technically correct that may be people just don't like doing work for some theoretical future benefit that may never materialize. Supporting 32-bit imposes a cost I have to pay right now today for the benefit of very few people (and a shrinking pool at that). Why not spend the effort on something more productive?

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.

That seems non-responsive, as none of those things mean that a pointer and a `long` have the same size. Did you intend to respond to someone else?

Google says "There are between 10^78 to 10^82 atoms in the observable universe." Even the lower number is (just slightly) greater than 2^256.

(Imagine installing 2^256 sound cards in a system ...)

One of the reasons, besides having the OS run on it, OpenBSD has the multiple architectures is to catch bugs based on non-portable assumptions - endian stuff, 32 vs 64 bit, memory alignment stuff etc.