On Sun, 2022-06-19 at 08:47 +0300, Eli Zaretskii wrote:
> > I do have a memory that some versions of Visual Studio, up until
> > relatively recently, have non-standard implementations of
> > snprintf()
> > but hopefully it's standard enough to manage this.
> If we now rely on ANSI-standard behavior of snprintf in the Windows
> port, we need the MinGW build to use -D__USE_MINGW_ANSI_STDIO=1, to
> force replacement of the MS version of snprintf with MinGW's own
> reimplementation, which is ANSI-standard.  That's because linking
> Make against MSVCRT.DLL will use a non-compliant snprintf in that DLL
> (MinGW cannot link against proprietary C runtime libraries that come
> with later versions of Visual Studio).

As best as I recall, the non-standard part of the old snprintf() was
that it returned -1 if the buffer wasn't large enough, rather than the
number of chars that would be needed.

The change made here doesn't rely on that behaviour.

However I realize now that I need to forcibly add a nul terminator
because the old snprintf() on Windows didn't nul-terminate the string
if the buffer wasn't large enough.

Maybe I'll just punt on that and simply allocate a large-enough buffer.

Were there other differences in old snprintf()?

Reply via email to