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

[Kim Barrett]

> 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.)