RFR: 8196882: VS2017 Hotspot Defined vsnprintf Function Causes C2084 Already Defined Compilation Error

[Kim Barrett]

> On Feb 21, 2018, at 8:47 PM, Kim Barrett <kim.barrett at oracle.com> wrote:
> 
>> On Feb 21, 2018, at 2:30 AM, Thomas Stüfe <thomas.stuefe at gmail.com> wrote:
>> src/hotspot/share/prims/jvm.cpp
>> 
>> Small behaviour change for input buffers of 0 and format strings of "". Before we returned -1, now (I guess) 0. Does any existing caller care? I looked but could not find anyone even checking the return code, so it is probably nothing.
> 
> You are right, that’s a change.  Well spotted.
> 
> I think the old behavior here, which matches the documentation, is
> probably preferable; it indicates we didn't even write a terminating
> NUL, so the buffer may not be terminated.  I'm going to change
> os::vsnprintf accordingly.  Of course, this is very much a corner case,
> since an empty format string is pretty rare.  But it could also arise with,
> for example, a format string of “%s” with an empty argument string.

While dealing with this I noticed the Visual Studio documentation for
_vsnprintf varies quite a bit from version to version in the description
of what happens with a 0 buffer size (including being an error in some
versions).  As a result, both the VS and POSIX versions of os::vsnprintf
will now just special case 0 buffer size and always return -1 for that,
indicating that not even the terminating NUL was written.  Good thing
you made me revisit that.