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 *".
