homepage

There's code like this in skipitem() in Python/getargs.c:
 case 'b': /* byte -- very short int */
 /* ... a zillion more case statements here ... */
 case 'C': /* unicode char */
 case 'p': /* boolean predicate */
 {
 (void) va_arg(*p_va, void *);
 break;
 }
 case 'n': /* Py_ssize_t */
 {
 (void) va_arg(*p_va, Py_ssize_t *);
 break;
 }
 /* ... a bunch of other stuff here ... */
 case 'S': /* string object */
 case 'Y': /* string object */
 case 'U': /* unicode string object */
 {
 (void) va_arg(*p_va, PyObject **);
 break;
 }
I cannot for the life of me imagine a platform where the size of a "Py_ssize_t *" or a "PyObject **" would be different from the size of a "void *". I've programmed on platforms where code pointers and data pointers were different sizes--but data pointers to different sizes of data? Never heard of it.
But I've been wrong before! So, rather than simply make the change, I'm posting this bug just as a double check.
It's safe to fold 'n', 'S', 'Y', and 'U' into the initial paragraph of case statements simply skipping a pointer... isn't it?

I'm not sure what you're proposing to fix. It seems to save at most a couple of lines of (obvious) code?
At least Py_ssize_t *could* have a different width from "PyObject *".

> I'm not sure what you're proposing to fix. It seems to save at
> most a couple of lines of (obvious) code?
Well, I *did* specify low priority.
Attached is the patch for what I had in mind.
> At least Py_ssize_t *could* have a different width from "PyObject *".
Not "Py_ssize_t", "Py_ssize_t *".

> > At least Py_ssize_t *could* have a different width from "PyObject *".
> 
> Not "Py_ssize_t", "Py_ssize_t *".
Ah, fair enough then. Looks ok to me.

New changeset 8ab37fa24e58 by Larry Hastings in branch 'default':
Issue #14746: Remove redundant paragraphs from skipitem() in Python/getargs.c.
http://hg.python.org/cpython/rev/8ab37fa24e58 

Thanks for the double-check. I should have more confidence!