Martin v. Löwis wrote: > "Tim Peters" <tim.one@comcast.net> 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 6.3.2.3p7: > > # 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 > given. FWIW, K&R 2nd Ed. says in A6.6 that this is only true if the conversion is to a type whose alignment requirement is less or equally strict. It also says that chars have the least strict alignment requirement. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4