[Python-Dev] ANSI strict aliasing and Python
Martin v. L÷wis
19 Jul 2003 03:07:47 +0200
"Tim Peters" <firstname.lastname@example.org> writes:
> > Notice that a compiler is allowed to infer that the test is always
> > false.
> I don't buy that. I'll buy that the result of the comparison is undefined
> by C, and that a hostile implementation of C could arbitrarily decide to
> call all such expressions false -- or arbitrarily decide to call all such
> expressions true.
You are right: it is undefined, so an implementation that always gives
false might still be conforming. The closest statement to defining
behaviour is 126.96.36.199p7:
# A pointer to an object or incomplete type may be converted to a
# pointer to a different object or incomplete type. If the resulting
# pointer is not correctly aligned57) for the pointed-to type, the
# behavior is undefined. Otherwise, when converted back again, the
# result shall compare equal to the original pointer.
So if you convert two pointers to the same PyIntObject to PyObject*,
and convert them back, then compare them, you are guaranteed to get
true. If you compare them while they are PyObject*, no guarantees are
> I don't buy that because C simply doesn't define the result of
> (PyObject *) &_Py_TrueStruct
> But that's not the point I was trying to make: the text of the warning
> message Neil quoted warned about dereferencing, but there is no
> dereferencing going on in the line it's complaining about.
So the message is confusing: I agree.
> I'm more worried about real problems <wink>:
But gcc is pointing to a real problem. It is just that it cannot, in
general, detect the real problem. As the real problem is wide-spread,
it makes a best effort approach in guessing what programs might show
As it turns out, in the case of Python, the compiler is right: There
is undefined behaviour with respect to PyObject*. We could cheat the
compiler to fail to recognize our bad cade, but it still would be bad
> Has anyone tried running Python compiled without no-strict-aliasing? If so,
> how bad was it?
The current change was primarily triggered by the messages. No single
bug was tracked down to gcc generating bad code in such cases.
> The other question is whether no-strict-aliasing prevents such
It does. gcc then assumes that any pointer may alias with any other.
> If it does, then we should probably always use it.