Sure, I thought I made that clear in my post. Also I didn't want to imply that this is good code or code anyone should write. However I still think when learning C or explaining the language it is vastly helpful to go with the analogy of pointers being integers, since it is so much easier to grasp. Which doesn't mean that shouldn't come with a big warning not to write weird unsafe code and everything; but even if the standard would actually mandate that any form if crazy pointer arithmetic would be defined behavior I wouldn't exactly encourage anyone to write code like that.

The sad truth is that I have seen, several times, people justifying real code doing questionable things with pointers in C(-like languages) by saying "well but pointers are just integers".

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.

There should be a different word for that though. A pointer is literally a stored memory address, i.e. an integer.

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

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