Note that the full NumPy testsuite passes for me locally on this branch if I simplify this conditional to always execute per diff below. If this is genuinely needed, it might be helpful to enforce the requirement with a test. If there's a good reason it is needed, but can't be tested, perhaps an explanatory comment might at least make sense.

--- a/numpy/_core/src/multiarray/convert.c
+++ b/numpy/_core/src/multiarray/convert.c
@@ -302,7 +302,7 @@ PyArray_ToFile(PyArrayObject *self, FILE *fp, char *sep, char *format)
             if (byteobj == NULL) {
                 Py_DECREF(strobj);
                 Py_DECREF(it);
-                if (n4 != 0) {
+                if (1) {
                     PyErr_SetString(PyExc_ValueError,
                             "The `format` parameter must contain only ASCII "
                             "characters.");

I'll add a test to catch this branch (e.g., str())

@tylerjereddy - OK, should see coverage on that branch with the extra test I pushed

I would be tempted to just stick with the unicode error either way. Sure, it's not necessary immediately clear it comes from the format itself, but I suspect it's clear enough?

@seberg I'd defer to you and @WarrenWeckesser, who originally proposed it.

It turns out it is probably better to stick with the unicode error as @seberg suggests. I hadn't considered Unicode string arrays in my initial comments in #31254. As it is now in the PR, if the array contains non-ASCII Unicode, and format="%s", the error message in the ValueError is not correct:

In [25]: np.__version__
Out[25]: '2.5.0.dev0+git20260416.dedf7c2'

In [26]: s = np.array(['λ123'], dtype='<U4')

In [27]: s.tofile('junk.dat', sep="; ", format="%s")
---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)
Cell In[27], line 1
----> 1 s.tofile('junk.dat', sep="; ", format="%s")

ValueError: The `format` parameter must contain only ASCII characters.

@WarrenWeckesser @seberg OK, see note below, hopefully this is what you were thinking for the format case

Can we please just use the error as-is? I don't think it is worth going through the trouble to validate the format string explicitly just to give it an explicit ValueError.

total nit but this should probably be labeled as an "improvement" rather than a "change"

Another way to handle the repeated cleanup code is to add a cleanup goto label below here that does Py_XDECREF on all the objects that need cleanup in error paths and then use goto cleanup in error paths above.

You can even define the return value like int ret = -1 in the function header and then set ret = 0 here and be sure then return ret in the cleanup code to unify the error paths and the happy path.

You also need to make sure that you initialize all the variables to NULL before the first use. The cost of this approach is some extra NULL checks which IMO is worth it for the improved maintainability and readability.

IMO that's better style for CPython C API code (despite the use of goto) because it avoids duplicate or almost-duplicate cleanup code which can sometimes be tricky to reason about.