Re: gl_{,SN}PRINTF_DIRECTIVE_N wrongly fail on Ubuntu 18.04

[Bruno Haible]

Hi Adrian,

> >...
> > it would
> > make sense for gnulib to have "nearly POSIX" compliant variants of these
> > functions; this would remove the need for the gnulib *printf* code in
> > many cases.
> 
> this sounds like a good idea.

Paul, Eric, what's your opinion on this?

> > --- a/doc/posix-functions/fprintf.texi
> > +++ b/doc/posix-functions/fprintf.texi
> > @@ -30,6 +30,7 @@ NetBSD 3.0, AIX 5.1, HP-UX 11.23, IRIX 6.5, Solaris 9,
> >  Cygwin 1.5.x, mingw, MSVC 14.
> >  @item
> >  This function does not support the @samp{n} directive on some platforms:
> > +glibc when used with @code{_FORTIFY_SOURCE >= 2}
> 
> _FORTIFY_SOURCE > 0, the glibc code is under
>       if ((mode_flags & PRINTF_FORTIFY) != 0)                                 

Sorry, but I verified on 3 systems (Ubuntu, Debian, Fedora) that
-D_FORTIFY_SOURCE=1 is like -D_FORTIFY_SOURCE=0, when it comes to this
test program.

> > (set by default on Ubuntu),
> >...
> 
> Ubuntu has enabled it by the default in gcc, which means you get it 
> by default not only for package building.
> 
> Debian/Gentoo/Fedora/openSUSE (including RHEL/SLES) all add
> _FORTIFY_SOURCE by default at least for building packages

The documentation we write is for the users of the plain 'gcc' program
(or vendor compilers). We can't consider the packaging systems of various
distros, as this is not something the user sees when compiling programs
as documented in the INSTALL file.

If you are among the packagers for a distro, you'll need to have knowledge
about the packaging systems and combine it with the knowledge you get from
the gnulib documentation.

Bruno