Bruno Haible <[EMAIL PROTECTED]> wrote: > 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.
%n is most definitely not "innocent". It is a commonly-exploited feature. >> 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. That is not relevant to my point. 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. Plus, that code is full of #ifdefs, many of which would disappear if it relied on a posix-conforming snprintf.
