"Tim Peters" <tim.one@comcast.net> writes:
> This is strange (according to me). The real point of adding that option
> would be to prevent bad code generation in the presence of pretty common
> non-standard C code, but I don't know why a compiler would complain about
> PyObject_IsTrue:
[...]
> if (v == Py_True) THIS IS LINE 1565 FOR ME
Notice that a compiler is allowed to infer that the test is always
false. Py_True is
#define Py_True ((PyObject *) &_Py_TrueStruct)
where _Py_TrueStruct is of type PyIntObject. A PyObject* could never
ever possibly point to a PyIntObject. If you still compare the two,
you obviously assume the language is not standard C.
> The way in which Python fakes inheritance by hand means there are potential
> problems all over the place (just about everywhere we cast to or from
> PyObject*), but very likely very few real problems. If the only ones gcc
> complains about involve Py_{True,False,None}, it's not being helpful.
These are the ones that gcc recognizes. It can and will generate bad
code all over the place.
Regards,
Martin
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