> A pointer is literally a stored memory address, i.e. an integer.

Consider:

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

What happens when 'a' is allocated to a CPU register? If 'b' never escapes and no (undefined) pointer arithmetic is used, the compiler can simply consider '*b' as an alias to '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.

> A pointer is literally a stored memory address, i.e. an integer

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.

> A pointer is literally a stored memory address, i.e. an integer.

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.

You're not wrong, but the segment/offset model is such a farce it's not even worth using as an example

(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)