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

[Kevin Walls]

Hi - Is anybody available to comment on this one...  Thanks!



On 13/07/2018 20:12, Kevin Walls wrote:
> 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
>