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

[Bruno Haible]

Jim Meyering wrote:
> When I build a coreutils snapshot with -D_FORTIFY_SOURCE=2 on a
> relatively recent fedora-based system, seq always aborts like this:
> 
>     $ ./seq 1
>     *** %n in writable segment detected ***
>     1zsh: abort      ./seq 1
>     [Exit 134 (ABRT)]
> 
> That is due to the fact that vasnprintf writes %n into a format
> string that is subsequently used by snprintf.

Use of %n is valid in ISO C99 and in POSIX.

At least Microsoft's C99 violation [1] [2] returns without processing the
%n. But letting a program crash for the attempt to use a C99 feature is
gross.

I haven't seen a valid rationale for this. Not on Microsoft's site.
[3] is vague. In [4] the real problem is the use of a user-provided string
as format string.

Can you ask these "Fortify" advocates for some rationale? Cutting down
innocent features without properly thought-out solution isn't going to win.

> This is why gnulib should be written to rely on posix- (or c99-)
> compliant functions whenever possible: so that conforming systems
> aren't penalized.

A system that ignores %n or even crashes upon it is not POSIX or C99
compliant.

Bruno

[1] http://lists.gnu.org/archive/html/bug-gnulib/2007-06/msg00048.html
[2] http://gcc.gnu.org/ml/gcc/2007-06/msg00122.html
[3] http://gcc.gnu.org/ml/gcc/2007-06/msg00145.html
[4] http://seclists.org/bugtraq/1999/Sep/0328.html