>> all systems providing correct >> sprintf() return values these days? ISTR that some C runtime >> implementations didn't correctly return the formatted length.
> 7th Edition Unix sprintf returned char * Perhaps the buffer is always big enough here. If not, though, then the more recent difference between SUSv2 (https://pubs.opengroup.org/onlinepubs/7908799/xsh/fprintf.html) and C99/POSIX (https://pubs.opengroup.org/onlinepubs/9699919799/functions/fprintf.html) on the returned value might come into it too (and might be what t'other Paul was thinking of). The Windows behavior changed "only" a decade ago too in a related way, according to https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/snprintf-snprintf-snprintf-l-snwprintf-snwprintf-l?view=msvc-170, which I'll quote directly because Microsoft URLs rot quicker than many: "Beginning with the UCRT in Visual Studio 2015 and Windows 10, snprintf is no longer identical to _snprintf. The snprintf behavior is now C99 standard conformant. The difference is that if you run out of buffer, snprintf null-terminates the end of the buffer and returns the number of characters that would have been required whereas _snprintf doesn't null-terminate the buffer and returns -1. Also, snprintf() includes one more character in the output because it doesn't null-terminate the buffer." (I don't understand that last sentence, though I would if it said _snprintf rather than snprintf.)
