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

[Kim Barrett]

> On Feb 27, 2018, at 3:01 AM, Marcus Larsson <marcus.larsson at oracle.com> wrote:
> 
> Hi Kim,
> 
> 
> On 2018-02-25 23:37, Kim Barrett wrote:
>>> On Feb 22, 2018, at 8:29 AM, Thomas Stüfe <thomas.stuefe at gmail.com> wrote:
>>> Just to voice my preference on this, I am okay with either version (c99 and returning -1 on truncation) but would prefer having only one global function, not two. Especially not a function which exists for the sole purpose of another component.
>>> 
>>> @Kim: thanks for taking my suggestions. I'll take another look when you post a new webrev.
>>> 
>>> Best Regards, Thomas
>> Based on discussion, I've changed the new os::vsnprintf and
>> os::snprintf to conform to C99.  For POSIX platforms, this just calls
>> ::vsnprintf.  For Windows, conditionalized to call ::vsnprintf for
>> VS2015 and later; earlier versions emulate that behavior using
>> _vsnprintf and _vscprintf.  Improved new gtest-based tests, so we
>> should quickly find out if some platform doesn't behave as expected.
>> 
>> I've also removed the now redundant os::log_vsnprintf, and changed
>> callers to use os::vsnprintf.
>> 
>> Also changed jio_vsnprintf to use os::vsnprintf, reverting some of the
>> ealier change.
>> 
>> An interesting point, which I'm not intending to address with this
>> change, is that vsnprintf only returns a negative value to indicate an
>> encoding error.  I think encoding errors can only arise when dealing
>> with wide characters or strings, e.g. when processing a %lc or %ls
>> directive.  I don't think HotSpot code would ever use either of those,
>> though perhaps call to jio_vsnprintf from outside HotSpot could.
>> Maybe the function we want for internal HotSpot use should return
>> unsigned (and internally error on an encoding error), as that might
>> simplify usage.
>> 
>> Updated webrevs:
>> full: http://cr.openjdk.java.net/~kbarrett/8196882/open.02/
>> incr: http://cr.openjdk.java.net/~kbarrett/8196882/open.02.inc/
>> 
>> (Ignore open.01*; open.02.inc is delat from open.00.)
> 
> Looks good! Many thanks for fixing.
> 
> Marcus

Thanks.  You might have missed open.03 though.