Re: vasnprintf's "%n in writable segment" chokes with _FORTIFY_SOURCE == 2

[Bruno Haible]

Jim Meyering wrote:
> The fact is that the current implementation in vasnprintf.c
> penalizes *all* systems for the sake of the few with snprintf
> that don't return a valid count.

It has a few more instructions than needed, for portability. When cross-
compiling, the gl_SNPRINTF_DIRECTIVE_N autoconf test can guess wrong.
But in the case you mention (glibc-2.3.4 or newer), we know that snprintf's
return value is usable. We have no other choice than to work around this broken
glibc behaviour:

2007-10-18  Bruno Haible  <address@hidden>

        * m4/vasnprintf.m4 (VASNPRINTF): Don't use %n on glibc >= 2.3 systems.
        Reported by Jim Meyering.

*** lib/vasnprintf.c.orig       2007-10-19 01:49:53.000000000 +0200
--- lib/vasnprintf.c    2007-10-19 01:47:50.000000000 +0200
***************
*** 3385,3393 ****
--- 3385,3405 ----
  #endif
                  *fbp = dp->conversion;
  #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
  #else
                fbp[1] = '\0';
  #endif