> In the bad old days of 386 segment:offset memory architectures this
> was a problem. You could have overlapping segments but pointers inside
> an object were always in the same segment, so the segment selectors
> never had to be inspected. Pointers to different objects could indeed
> have the same offset and would compare equal.

AFAIK it caused lots of other problems much more annoying than just
pointer compares, and programmers had to juggle by hand with various
addressing modes (near, far, etc.).

ISTM that all C programs nowadays assume some kind of flat, paged memory
model, CPython included; I don't think we have to fear some i386-like
segmentation model.

> We should follow the standard here: no comparisons between pointers to
> different arrays (basically).

Again, what is an "array" supposed to be? In memory there are no
"arrays".

Let's say I have the following function in a module:

int ptr_compare(char *a, char *b)
{
   return a > b;
}

and another module, the following function

int foo()
{
    static char x[5];
    static char y[6];
    return ptr_compare(x + 2, y + 3);
}

How is the compiler supposed to know whether a and b belong to the same
array when compiling ptr_compare?

Otherwise, we could cast to Py_uintptr_t.