WIP: Fix makefilename
This fixes a plethora of memory errors and segfaults from [makefilename]
. These segfaults can occur in the current Purr Data and in the recent attempts at fixes to [makefilename]
in Pd Vanilla.
Additionally this limits the width and precision fields to 3 digits. 999 should be enough digits for any of the crazy tricks users are doing with [makefilename]
well outside of its original use case. That takes care of another out-of-memory crasher that can currently occur in both Purr Data and Pd Vanilla.
Finally, the lib call to actually fill in the format string is wrapped using vsnprintf to ensure that the output does not exceed MAXPDSTRING. That should take care of all outstanding problems with [makefilename]
.
I went through and documented each step of the parser that checks well-formedness for the subset of C lib format specifier used by Pd. Badly formed args thus get an error message reporting exactly which part of the specifier is badly formed.
One outstanding issue:
- I haven't studied whether the attempted Pd Vanilla fix broke other things like expected output on empty string, sending a symbol for float or int specifiers, sending float for '%s' specifier, etc. If someone wants to beat me to that go ahead. Otherwise I'll check in a few days, perhaps write some tests, then merge this.
tl;dr You'd better pray that none of the 100+ million lines of code in the vehicle you are driving allow arbitrary input in a C string lib format specifier.