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

[Thomas Stüfe]

Kim, Marcus,

On Thu, Feb 22, 2018 at 10:52 AM, Kim Barrett <kim.barrett at oracle.com>
wrote:

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