gh-111178: fix UBSan failures in Modules/posixmodule.c

[picnixz]

This PR fixes the UBSan failures and addresses some minor cosmetic changes. PEP-7 changes were not applied since they could scramble the diff but other semantic changes affecting the signature of touched functions may have been done.

• Issue: UBSan: Calling a function through pointer to incorrect function type is undefined behavior #111178

[vstinner]

LGTM

[picnixz]

There was a redundant cast that I missed. I also renamed some parameters that I incorrectly renamed (using Py_UNUSED(ignored) is useless, it doesn't tell you at first glance whether it's a NOARGS or a ONEARG/VARARGS method while Py_UNUSED(dummy), Py_UNUSED(arg) and Py_UNUSED(args) would tell you more).

[encukou]

using Py_UNUSED(ignored) is useless, it doesn't tell you at first glance whether it's a NOARGS or a ONEARG/VARARGS method while Py_UNUSED(dummy), Py_UNUSED(arg) and Py_UNUSED(args) would tell you more

FWIW, I'm skeptical here -- I don't think we can make it reliably tell you more. But, if it doesn't matter, why not use your suggestions.

[picnixz]

don't think we can make it reliably tell you more

The thing is that I saw one usage of void *ignored although it should have been PyObject *unused (#130446), however this was hidden behind a #ifdef MS_WINDOWS and removing the PyCFunction cast introduced a compilation error that I didn't see. For me "ignored" or "unused" means that we can possibly use the argument later. However "dummy" really means for me "it's just a placeholder, we'll never use it later" (I'm only using dummy for NOARGS method, not for VARARGS that actually ignore their args value).

The semantic change I usually do is unused to closure because the closure parameter is generally really for getter/setter and not for methods.