RFR: 8336289: Obliterate most references to _snprintf in the Windows JDK

[Kim Barrett]

On Fri, 12 Jul 2024 06:29:34 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> snprintf has been available for all officially and unofficially supported compilers for Windows, Visual Studio since version 2015 and gcc since, well, forever. snprintf is conforming to C99 since the start when compiling using gcc, and 2015 when using Visual Studio. Since it conforms to C99 and provides better semantics than _snprintf, and is not compiler specific, we should use it in most places where we currently use _snprintf. This makes JDK code where this is used more robust due to the null terminating guarantee of snprintf. Since most of the changes are extremely simple, I've included all of them hoping to get this all done in one shot. The only places _snprintf is not replaced is places where I'm not sure whether the code is ours or not (As in, imported source code for external libraries). Note that the existing checks in place for the size of the characters written still work, as the return value of snprintf works mostly the same as _snprintf. The only difference is the nul
 l terminating character at the end and the returning of the number of written characters if the buffer was terminated early, as seen here: https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/snprintf-snprintf-snprintf-l-snwprintf-snwprintf-l?view=msvc-170
> 
> Reviews Required: 2 for HotSpot, jdk.hotspot.agent, and jdk.jdwp.agent, 1 for awt and jdk.accessibility, 1 for java.base, 1 for security, 1 for jdk.management(?)

This should be using `os::snprintf` rather than `snprintf`.  Rationale is in the comment here:
https://github.com/openjdk/jdk/blob/1f6e106b45e5109224e13d70f1a40c9e666ec2ab/src/hotspot/share/runtime/os.cpp#L118-L126

And yes, I know there are lots of bare uses of snprintf (about 125?), including in shared code.  That's why it isn't
currently in the forbidden list.  There's some cleanup to do there.

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

PR Comment: https://git.openjdk.org/jdk/pull/20153#issuecomment-2226218368