More damage to intuition (was RE: [Python-Dev] Comparison of recursive objects)

[Tim Peters]

[Thomas Wouters]
> Why is comparing v->ob_type with w->ob_type illegal ? They're
> both pointers to the same type, aren't they ?

Non-equality comparison of pointers is defined if and only if the pointers
are both addresses in the same contiguous structure (think struct or array);
an exception is made for a pointer "one beyond the end" of an array, i.e. if

    sometype a[N];

then &a[0] < &a[N] == 1 is guaranteed despite that &a[N] is outside the
bounds of a; but &a[0] < &a[N+1] is undefined (which *means* undefined!
e.g., it's OK if they compare equal, or if the comparison causes a hardware
fault, or ...).

> That's easy to check, gcc has these nice (and from a users point of view,
> fairly useless) options: '-ansi', '-pedantic' and '-pedantic-errors'.
> '-ansi' disables some GCC-specific features, -pedantic turns gcc into a
> whiney pedantic I'm sure you'd get along with just fine <wink>, and
> -pedantic-errors turns those whines into errors.

Your faith in gcc is as charming as it is naive <wink>:  the most
interesting cases of undefined behavior can't be checked no-way, no-how at
compile-time.  That's why Barry keeps talking employers into dumping
thousands of dollars into a single Insure++ license.  Insure++ actually tags
every pointer at runtime with its source, and gripes if non-equality
comparisons are done on a pair not derived from the same array or malloc
etc.  Since Python type objects are individually allocated (not taken from a
preallocated contiguous vector), Insure++ should complain about that
compare.

> ...
> Note that this was tested in a current tree. I couldn't find
> either Guido's 'broken' code or your proposed 'good' code, so I
> don't know if you checked in a fix yet. If you didn't, don't bother,
> it's not broken :-)

Guido hasn't checked it in yet, but gcc isn't smart enough to detect *this*
breakage anyway.