"Thomas Heller" <thomas.heller@ion-tof.com> writes: > At least descrobject.c, cPickle.c and funcobject.c defines PyGetSetDef > arrays which use function signatures where the last void* parameter is > missing. While obviously this does no harm (so far), it is surely a bug > (or am I missing something)? In the sense of strict C, this is a bug - the function is called with the closure present, so it must also be declared with the closure. Most C implementations support calls where the caller provides more arguments than the callee consumes, for compatibility with K&R C, so this is not a problem. Still, it should be changed, IMO. > Related: I am always wondering, why the compiler (MSVC 6 in my case) > gives a warning when you use these signatures for getter/setter functions > > PyObject *get(wrapperobject *, void *) > int set(wrapperobject *, PyObject *, void *) > > (warning C4028: formal parameter 1 different from declaration), > while if I use these signatures > > PyObject *get(PyObject *) > int set(PyObject *, PyObject *) > > the compilation gives no warning at all. Another MSVC glitch? MSVC is right when giving the warnings about the first set of signatures: You cannot convert PyObject*(*)(wrapperobject*,void*) to PyObject*(*)(PyObject*,void*). Apparently, it sees no problem with the conversion of PyObject*(*)(PyObject*) to PyObject*(*)(PyObject*,void*), which, again, could be for compatibility with K&R C (function pointer type can be converted if the argument types of one function are an initial sequence of the argument types of the other). Just see whether compiling in strict C mode changes anything. 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