On Fri, Jan 9, 2026 at 12:39 AM Thiago Macieira wrote:
>
> In fact, the most common use won't use two pointers, but a pointer and a
> generation counter. "atomic_pointer_pair" would be semantically the wrong
> type.


The type "int" started out as the natural integer type for a given
architecture -- which means the width of the CPU registers.

I remember when I was a young child, and my father brought home an
Intel 80286 computer with pink CGA graphics, I'll never forget the
'Amy' kids' game (it's amazing how I still have the memory so clear).
The AX register was 16-Bit. So 'int' was 16-Bit.

Then the 80386 came out afterward with EGA graphics. The EAX register
was 32-Bit, so int became 32-Bit.

However when moving from x86_32 to x86_64, the RAX register was
64-Bit, but too many lack-lustre programmers had assumed 32-Bit int's
in their code, and so 'int' wasn't bumped up to 64-Bit.

So now the natural type for a given architecture is not 'int', but
rather 'intptr_t' -- and I actually use this type in my code when I
want "the natural integer type".

In choosing the name for the type "atomic_pointer_pair", the 'pointer'
part really just means "the register width". That's why the member
functions of atomic_pointer_pair will allow you to access either of
the pointers as intptr_t, so that when you're writing a lockfree
container you can have "pointer + counter".