JDK-8196882 : VS2017 Hotspot Defined vsnprintf Function Causes C2084 Already Defined Compilation Error
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 11
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: windows
  • Submitted: 2018-02-06
  • Updated: 2020-04-12
  • Resolved: 2018-02-27
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 11 JDK 7 JDK 8
11 b04Fixed 7u211Fixed 8u202Fixed
Related Reports
Relates :  
JDK-8198906 - JDK-8196882 breaks VS2013 Win32 builds
Description
abstractInterpreter.cpp
<directory>\open\src\hotspot\share\utilities/globalDefinitions_visCPP.hpp(173): error C2084: function 'int vsnprintf(char *const ,const ::size_t,const char *const ,va_list)' already has a body
<directory of installed VS2017>\vs2017~1.0\devkit~1.gz\10\include\ucrt\stdio.h(1428): note: see previous definition of 'vsnprintf'
Comments
There is an inline definition of vsnprintf in globalDefinitions_visCPP.hpp, to provide the behavior we want, which is to guarantee a terminating NUL. It also returns -1 on truncation (the original SUSv2 behavior). This is the same as our jio_vsnprintf. That inline definition is now problematic, because recent versions of Visual Studio also provide a (conflicting) inline definition. That new definition conforms to the C99 specification. We also have various callers which attempt to account for the different behaviour of vsnprintf on Windows vs POSIX.
16-02-2018