This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author pitrou
Recipients amaury.forgeotdarc, eric.smith, mark.dickinson, pitrou, rhettinger, stutzbach
Date 2010-10-07.21:29:37
SpamBayes Score 1.7020585e-07
Marked as misclassified No
Message-id <1286486974.3143.15.camel@localhost.localdomain>
In-reply-to <>
> 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

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.
Date User Action Args
2010-10-07 21:29:39pitrousetrecipients: + pitrou, rhettinger, amaury.forgeotdarc, mark.dickinson, eric.smith, stutzbach
2010-10-07 21:29:37pitroulinkissue10044 messages
2010-10-07 21:29:37pitroucreate