RFR: 8296812: sprintf is deprecated in Xcode 14 [v6]

[Kim Barrett]

On Wed, 16 Nov 2022 09:06:22 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Updated to use the result from `os::snprtinf` in the new commit.
>
>> A result of -1 only occurs for an encoding error. An encoding error is only possible with multi-byte / wide characters. (See the definition of "encoding error" in C99 7.19.3/14.) We don't use those, so there won't be any encoding errors, so our uses of snprintf never return -1.
> 
> Hi @kimbarrett,
> 
> I am not sure this was true. E.g. https://stackoverflow.com/questions/65334245/what-is-an-encoding-error-for-sprintf-that-should-return-1 cites some cases where snprintf returns -1 that have nothing to do with multibyte strings. Also, size=0  would return -1 according to SUSv2.
> 
> Note glibc differs and returns the number of chars it *would* have printed. Which is also dangerous in a different way. If you use that number to update the position, the position is not limited to buffer boundaries. So, I think the result of os::snprintf should not be used to update buffer position, at least not without checking.

SUSv2 is *ancient*. That got fixed in SUSv3 / POSIX.1-2001. From the Linux man
page for snprintf:

"Concerning the return value of snprintf(), SUSv2 and C99 contradict each
other: when snprintf() is called with size=0 then SUSv2 stipulates an
unspecified return value less than 1, while C99 allows str to be NULL in this
case, and gives the return value (as always) as the number of characters that
would have been written in case the output string has been large enough.
POSIX.1-2001 and later align their specification of snprintf() with C99."

For many/most places where we might use the return value, an assert of no
truncation would be appropriate. (Esp. likely in places where sprintf was
being used correctly.) Though there are probably places where something more
is needed.

-------------

PR: https://git.openjdk.org/jdk/pull/11115