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()?
