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