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

[Kim Barrett]

> On Feb 22, 2018, at 3:30 AM, Marcus Larsson <marcus.larsson at oracle.com> wrote:
> On 2018-02-22 05:20, Kim Barrett wrote:
>>> 
>> There was discussion of the behavior in this area around JDK-8062370
>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-November/015779.html
>> 
>> The consensus then was that a guarantee of NUL-termination was
>> desirable. That's already at variance with C99 vsnprintf.
> 
> From what I can tell, C99 guarantees NUL-termination (for n > 0, naturally).

Hm, you are right.  C99 is quite explicit about that.  I should have looked there,
rather than relying on the man page description.  I’ve been reading the Linux
snprintf(3) man page as saying it doesn’t nul-terminate on truncation.  But looking
at it again, in light of the C99 text, I’d now say the man page is ambiguous.  Okay,
that should simplify things a bit.

>> So being consistent with C99 vsnprintf doesn't appear to be useful in
>> this code base, would add some cost to converting away from using the
>> jio_ functions in order to get the -Wformat warnings, and might add
>> some (likely not really measurable) performance cost for Windows.
> 
> Just for the record: Starting with VS2015, (v)snprintf implementations are C99 conforming.

Yes.  Not yet throwing out support for at least VS2013 though.

>> So I'm not inclined toward making the return value from os::vsnprintf
>> consistent with C99 vsnprintf. If there's a groundswell of support, it
>> can be done, but I'd rather keep such an effort separate from this
>> change, which is intended to address a problem with building using
>> recent versions of Visual Studio, doing a little bit of cleanup in the
>> process.
> 
> That's fine with me, I just wanted to voice my opinion on the API I would prefer. Also that keeping two implementations of essentially the same thing seems weird to me (vsnprintf vs log_vsnprintf).

I’d be okay with the C99 behavior.  It means the jio_ functions differ though,
which makes it harder to do the suggested conversion, as there are ~55 callers
that use the return value.