I am working with Python since 5 years (and on Python since 3 years): I never seen any garbage string in error messages. My concern is to not truncate strings in error messages anymore. I consider that it is more important than using a hack to workaround some crashs.

I call %.100s a hack because on a buffer overflow, other attributes are overwritten, and I think that the other attributes are more important than tp_name and the program will crash quickly. Try a buffer overflow on PyLong_Type and check how much time does it take to crash Python: I bet that the program will crash before formatting any exception.

> Indeed, there are no PyErr_Format(PyExc_MemoryError, ..) in the code
> base, but there are a few PyErr_SetString(PyExc_MemoryError, ..) such
> as PyErr_SetString(PyExc_MemoryError, "math.fsum partials") in
> Modules/mathmodule.c.  Maybe these should be reviewed.

This instruction comes from math.fsum() which allocate a new list with the size of the input size (not exactly, but it is based on the size of the input list). Python may fail to allocate an huge list, but it doesn't mean that it will be unable to allocate memory for the short string "math.fsum partials". Anyway, if the allocation of "math.fsum partials" string fail, another MemoryError (without any message) will be used. So it doesn't really matter.

> Still, there may be code paths where OOM triggers an error other 
> than MemoryError.

Same than before: Python should be able to allocate the new error object, and if it fails: it will use MemoryError anyway.

> In any case, I don't see anything wrong with
> using fixed size buffers in error handling and truncating too long
> output.

I consider that there is no more good reason to truncate strings, I want to see the full error message!