Hi! I received a patch for vasnprintf with rationale:
> - fixes vasnprintf for MSVC8 or higher that has also %n blocked
The patch was:
--- a/lib/gl/vasnprintf.c
+++ b/lib/gl/vasnprintf.c
@@ -4008,7 +4008,7 @@ VASNPRINTF (DCHAR_T *resultbuf, size_t *lengthp,
#endif
*fbp = dp->conversion;
#if USE_SNPRINTF
-# if !(__GLIBC__ > 2 || (__GLIBC__ == 2 && __GLIBC_MINOR__ >= 3))
+# if !(__GLIBC__ > 2 || (__GLIBC__ == 2 && __GLIBC_MINOR__ >= 3) || (_MSC_VER
>= 1400))
fbp[1] = '%';
fbp[2] = 'n';
fbp[3] = '\0';
The current code is:
#if USE_SNPRINTF
# if !(__GLIBC__ > 2 || (__GLIBC__ == 2 && __GLIBC_MINOR__ >= 3))
fbp[1] = '%';
fbp[2] = 'n';
fbp[3] = '\0';
# else
/* On glibc2 systems from glibc >= 2.3 - probably also older
ones - we know that snprintf's returns value conforms to
ISO C 99: the gl_SNPRINTF_DIRECTIVE_N test passes.
Therefore we can avoid using %n in this situation.
On glibc2 systems from 2004-10-18 or newer, the use of %n
in format strings in writable memory may crash the program
(if compiled with _FORTIFY_SOURCE=2), so we should avoid it
in this situation. */
fbp[1] = '\0';
# endif
Looking at this, I'm not sure I understand the intention. Why isn't a
configure test used to determine whether %n works in snprintf or not (if
that is indeed what is relevant), rather than version-based checks?
There seems to be some m4 checks for this already.
It seems that MSVS8 also crash (or "block") %n in format strings. Is
the patch the right thing?
/Simon
