vasnprintf.c %n blocked under MSVS8

[Simon Josefsson]

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