RFR: 8213622 - Windows VS2013 build failure - "'snprintf': identifier not found"

[Kim Barrett]

> On Nov 9, 2018, at 6:07 PM, David Holmes <david.holmes at oracle.com> wrote:
> 
> cc'ing JC Beyler as this was his code.
> 
> On 10/11/2018 4:35 AM, Kim Barrett wrote:
>>> On Nov 9, 2018, at 11:43 AM, Michal Vala <mvala at redhat.com> wrote:
>>> 
>>> Hi,
>>> 
>>> please review following patch fixing build failure on Windows with VS2013 toolchain.
> 
> Not sure we're still supporting VS2013 ... ??

For now, we still claim to support VS2013; it's listed in the
supported versions in make/autoconf/toolchains_windows.m4.  That will
change with JDK-8208089 (if not sooner).

>>> http://cr.openjdk.java.net/~mvala/jdk/jdk/JDK-8213622/webrev.00/
>> The failure is in a hotspot test.  It should be using os::snprintf.
> 
> Tests don't have access to os::snprintf. The test is just C++ code.

Drat!  Yeah, we don't seem to have access to VM code from these test
support codes.  That's too bad.

However, the proposed change doesn't work as intended.

There are two calls to snprintf in ExceptionCheckingJniEnv.cpp, which
would be affected by the proposed change. The first is calling
snprintf with an empty buffer to determine the size of the needed
buffer. _snprintf returns -1 on buffer overflow, rather than the
number of characters that would have been printed if the buffer size
was sufficient to hold the output. So replacing that snprintf call
with _snprintf will return a very different result from what is
expected. I don't see a simple way to solve this while retaining the
source calls to snprintf.

That first snprintf call could be rewritten using several calls to
strlen to calculate the needed size in some different manner. The
later call could also be rewritten to use several calls to strcpy
rather than snprintf.

I think there currently aren't any other calls that would be affected,
even though there are other #includes of the file being changed.  But
that's not trivial to check, and could change, possibly leading to
hard to fathom bugs.

There are 8 other calls to snprintf in test/hotspot/jtreg.  Most of
them are linux-only or solaris-only, so don't trip over the lack of
snprintf on windows.

However, one if them, in jvmti_tools.cpp, I think is applicable to
Windows.  It builds because it uses the renaming macro approach, with
the macro being in jvmti_tools.h.  Yuck (IMO).