https://bugs.exim.org/show_bug.cgi?id=1801
--- Comment #5 from Roy Ivy III <Roy.Ivy.III@???> ---
So, it turns out that MinGW GCC uses the MSVC _snprintf() which does not
conform to the C99 specification for snprintf().
Since at least VC6 (cl 12.00), MSVC has had _snprintf() which exhibits the
following characteristics:
* returns -1 for insufficient buffer capacity/size
* NUL-terminates only if buffer capacity/size >= (size of formatted output)+1
All current versions of MinGW GCC, up to at least 5.1.0, and for both
snprintf() or _snprintf(), call this MSVC _snprintf() function.
So, I'm if it's a bug or expected behavior. I'll post an issue on the MinGW-W64
bug tracker (
https://sourceforge.net/p/mingw-w64/bugs) when I get some more
time.
Notably, in MSVC 14/2015, a C99 conforming snprintf() was added:
* returns length of output regardless of buffer capacity/size
* NUL-terminates if buffer capacity/size > 0
The non-conforming _snprintf() is also still present.
refs:
[snprintf and Visual Studio 2010]
http://stackoverflow.com/questions/2915672/snprintf-and-visual-studio-2010/8712996#8712996
@@
http://archive.is/6Oqeq
[Using snprintf in a cross-platform application]
http://stackoverflow.com/questions/3976306/using-snprintf-in-a-cross-platform-application/21929706#21929706
@@
http://archive.is/D26MZ
[Using snprintf to avoid buffer overruns]
http://stackoverflow.com/questions/1775403/using-snprintf-to-avoid-buffer-overruns
@@ http://archive.is/cbYyC
... see
When I was using MinGW one or two years ago, it actually called Microsoft's
_snprintf(), which doesn't behave like the standard snprintf() (I think it
doesn't always nul-terminate the string).
- Bastien Léonard
[snprintf() on different platforms]
http://demin.ws/blog/english/2013/01/28/use-snprintf-on-different-platforms @@
https://archive.is/9TdSa
--
You are receiving this mail because:
You are on the CC list for the bug.
