RFR (XS) 8219583: Windows build failure after JDK-8214777 (Avoid some GCC 8.X strncpy() errors in HotSpot)

[Kim Barrett]

> On Feb 22, 2019, at 3:44 PM, Aleksey Shipilev <shade at redhat.com> wrote:
> 
> On 2/22/19 9:42 PM, Aleksey Shipilev wrote:
>> On 2/22/19 8:56 PM, Kim Barrett wrote:
>>>> New code introduced in JDK-8214777 calls to "naked" snprintf, which fails to compile in my Windows
>>>> configs. It seems to be the omen to replace these with the usual jio_snprintf calls. There is also
>>>> os::snprintf we can use instead, but shared runtime code really likes jio_snprintf, and it will
>>>> delegate as needed.
>>> 
>>> Please use os::snprintf: https://bugs.openjdk.java.net/browse/JDK-8198918
>> 
>> Even if the same file (and other files in those components) use jio_snprintf, right? I did the first
>> patch with os::snprintf, but reverted it on stylistic grounds. No validation with -Wformat sounds
>> ominous, though.
> 
> Remembered that I still have os::snprintf version handy:
>  http://cr.openjdk.java.net/~shade/8219583/webrev.01/
> 
> -Aleksey

Looks good.

In the bug it is suggested the problem might only affect builds with
--disable-precompiled-headers.  I don't think that's the problem here,
as the failure is in a .cpp.  Instead, I suspect the failure is
occuring when using an older version of Visual Studio that doesn't
provide snprintf; it's a pretty recent addition.  See 
https://mail.openjdk.java.net/pipermail/hotspot-dev/2018-November/035141.html

A fix for JDK-8214976 could have caught this much earlier.  I'm trying
to get someone to take that on.