[Python-Dev] getter/setter function signatures

[Martin v. Loewis]

"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