Arguing about these assembly/CPU-level details (unfortunately?) is besides the point when debating the semantics of languages like C, C++ or Rust.

Because it'd be pretty odd for the page to change after first read from operating system implementation point of view. Generally I'd expect the default mapping to be to an all-zero physical memory page. (Unless there's a rowhammer attack (or similar) that successfully modifies said all-zero page...)

From C/C++ point of view, it's legal for uninitialized memory to arbitrarily change between (undefined behavior) reads until it is written to.

While I doubt any actual OS would modify the page in this manner after first read access, a C/C++ compiler can still return arbitrary (even random) values when reading from uninitialized memory. It doesn't even need to actually read from the memory proven to be uninitialized.

They'll even move the page to the harddisk if necessary. Or am I misunderstanding what you're asking?

(Not that I would've recommended using uninitialized bytes as an RNG anyways ;))

This is all about the abstract model used for optimization according to the language specification.

I am not sure what the best way to teach C is. Maybe it is a good idea to start with a "lie" and explain pointers as integers. But most C books/tutorials never go to the part where they explain that this is a lie, and that is a problem. The problem will only get worse as compilers get smarter and hence better at exploiting the UB that lurks in so many programs due to a naive treatment of pointers.

The thing the compiler manipulates could be called a "C pointer" or something.

Consider:

  int a = 5;
  int* b = &a;

In this case the 'pointer' never actually points to memory.

> The thing the compiler manipulates could be called a "C pointer" or something.

Perhaps, although when talking about pointers, it's almost always in context of a particular programming language.

Maybe it'd be better to talk about "hardware pointers". Although on hardware level, from CPU point of view, a value or a register generally only becomes a "pointer" when it's used to compute a memory address for an instruction that accesses memory. (Excluding special hardware registers, like instruction pointer, page tables, DMA hardware or interrupt/exception vectors.)

So a "pointer" is always an abstraction in context of general purpose processing.

You’re mixing implementation with definition. A pointer is (usually) implemented in terms of an integer (i.e. its physical representation is a sequence of bytes interpreted as an integer offset in memory). But that isn’t what a pointer is. The C++ standard (or the C standard, or Rust, or any of many other languages) defines pointers as a concept that has all kinds of properties that integers don’t have. The whole point of this blog post is that this distinction is crucial in order to guarantee type safety and allow the compiler to perform basic optimisations.

This is not correct in general. In x86 real mode, addresses consist of a segment and an offset. The linear address is computed as segment * 16 + offset. This is very different from a single integer, and even somewhat different from a pair of integers: Two different segment/offset-pairs can refer to the same linear address, so a pointer comparison has to behave differently than an integer-pair comparison.

(also you would have had to distinguish between far and near pointers)

At the processor level, pointers are distinguished either by the type of register or by the type of operation used on them (when they're more orthogonal, still there are "pointer only" registers like stack, ip, etc)