[8u] RFR: 8196882: VS2017 Hotspot Defined vsnprintf Function Causes C2084 Already Defined Compilation Error

[Kevin Walls]

Hi,

I'd like to request a review of a backport from 11 to 8u:

8196882: VS2017 Hotspot Defined vsnprintf Function Causes C2084 Already 
Defined Compilation Error
JBS: https://bugs.openjdk.java.net/browse/JDK-8196882

11 changeset:
http://hg.openjdk.java.net/jdk/hs/rev/eebf559c9e0d

11 review thread:
http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-February/030252.html
...to...
http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-February/030279.html


8u webrev: http://cr.openjdk.java.net/~kevinw/8196882/webrev.00/


 From VS2015, vsnprintf is provided, and is C99 conforming.  This is 
new, and
conflicts with the hotspot-provided definition.  8196882 introduces 
os::vsnprintf()
so we can choose what we call in there.

We don't necessarily want to change behaviour in jdk8u, so we call 
_vsnprintf()
on Windows to get the old behaviour.

I didn't plan to move everything to a C99 behaviour here for jdk8u as we 
did in jdk11.
We just want to solve the symbol clash, so outputStream::do_vsnprintf() 
does
not need to change as it does in 11.

In jvm.cpp, the change in jdk11 changes jio_vsnprintf behaviour, but we 
wouldn't
normally choose to change the behaviour at this point in 8u.

(But ensuring the buffer is null-terminated looks like a positive change.)

The original has GTests, here in 8u it's a debug-mode test at runtime.  
I have edited some of the
asserts in check_snprintf_result() as not changing jio_vsnprintf.

I've been building and testing with VS2017 and the current default 
compiler VS2010,
plus the other platforms.

Many thanks!
Kevin