'countformat' does not appear to be handling the case where a format string is passed with no parenthesis or brackets correctly. Here is an
example of a usage that might cause issues from typedobject.c:

static PyObject*
slot_sq_slice(PyObject *self, Py_ssize_t i, Py_ssize_t j)
{
	static PyObject *getslice_str;

	if (PyErr_WarnPy3k("in 3.x, __getslice__ has been removed; "
			    "use __getitem__", 1) < 0)
		return NULL;
	return call_method(self, "__getslice__", &getslice_str,
		"nn", i, j);      <<<<<<< Maybe Bad Format Str <<<<<<<
}

The format string "nn" does not have any level markers so when it gets
processed by 'countformat' the count will be incremented 2 times by the
'default' case but when the end of the string is reached and the NULL character is processed bay "case '\0':".  The function will ignore the count variable and just return -1 anyway.  The error created is unmatched paren in format but 'level' is never checked to see if a paren
was even hit to begin with.

It might be that the case should be changed to look at level before assuming a error condition if strings are supposed to be processed as the one in the example above.  case '\0' should probably be doing something like:

         case '\0':
            if (level > 0) {   // Check If Level Was Incremented
                /* Premature end */
                PyErr_SetString(PyExc_SystemError,
                                "unmatched paren in format");
                return -1;
            }
            break;

Can you post a reproducer?

There is not reproducer for this currently.

Its a case of implied or shared usage between a function and the code that uses it.  This function is only used in the Python core, so unless
it is used incorrectly, by a python extension or modification, it may never hit the error condition.

The case where this will fail is if for some reason it is called with
a 'endchar' other than '\0'.  The function assumes end char will be '\0', ')', ']', and ']'.

There are format string like "O&O&O&O&O&" being passed in to Py_BuildValue which eventually make their way to 'countformat'.  It looks like it would just break after the first & and not count anything else.  So Im not sure it gives an accurate count.

I am not seeing any problem. The function is declared static, and is only called with nonzero endchar from do_mkvalue() that I can see. It should not be directly callable from elsewhere.

Yes, there are some other cases that look odd to me as if the code is not up to date though.  I was looking at the documentation and it mentions format character combinations like 'es' which contain two characters sequences.  When I look at this function, it does not handle two character sequences so the count in some cases may not be correct.  Im not familiar with the code enough to know how critical the count might be.

The breaking for “&” is to keep the count right, because the preceding “O” would already have been counted as one. The “es” code is only documented for parsing values, not for building values. I suggest to close this, unless you can find a specific bug.