Subject: Re: bug#5999: new snapshot available: coreutils-8.4.100-81926

From: "Gilles Espinasse" <[email-masked]>
Date: Tue, 27 Apr 2010 07:44:43 +0200

----- Original Message ----- 
From: "Bruno Haible" <[email-masked]>
To: "Paolo Bonzini" <[email-masked]>
Cc: "Jim Meyering" <[email-masked]>; "Gilles Espinasse" <[email-masked]>;
<[email-masked]>; <[email-masked]>
Sent: Tuesday, April 27, 2010 1:27 AM
Subject: Re: bug#5999: new snapshot available: coreutils-8.4.100-81926

> Paolo Bonzini wrote:
> > > Here's a patch to make that diagnostic go where it belongs
> > > for all gnulib-using projects:
> >
> > I wonder if we shouldn't do that for all _autoconf_-using projects!
>
> Or, at least, for all tests in all gnulib-using projects. There are
> more possible causes of a FORTIFY message, according to
>   <https://wiki.edubuntu.org/CompilerFlags>
>
> How about this proposed patch?
>
>
> 2010-04-26  Jim Meyering  <[email-masked]>
>             Bruno Haible  <[email-masked]>
>
> * m4/gnulib-common.m4 (gl_COMMON_BODY): Set LIBC_FATAL_STDERR_.
>
> --- m4/gnulib-common.m4.orig Tue Apr 27 01:25:33 2010
> +++ m4/gnulib-common.m4 Tue Apr 27 00:01:03 2010
> @@ -1,4 +1,4 @@
> -# gnulib-common.m4 serial 19
> +# gnulib-common.m4 serial 20
>  dnl Copyright (C) 2007-2010 Free Software Foundation, Inc.
>  dnl This file is free software; the Free Software Foundation
>  dnl gives unlimited permission to copy and/or distribute it,
> @@ -35,6 +35,12 @@
>     is a misnomer outside of parameter lists.  */
>  #define _UNUSED_PARAMETER_ _GL_UNUSED
>  ])
> +  dnl Preparation for running test programs:
> +  dnl Tell glibc to write diagnostics from -D_FORTIFY_SOURCE=2 to stderr,
not
> +  dnl to /dev/tty, so that can be redirected to log files. Such
diagnostics
> +  dnl occur e.g. in the macros gl_PRINTF_DIRECTIVE_N,
gl_SNPRINTF_DIRECTIVE_N.
> +  LIBC_FATAL_STDERR_=1
> +  export LIBC_FATAL_STDERR_
>  ])
>
>  # gl_MODULE_INDICATOR_CONDITION

I understand there is a problem but I am unsure of the direction to go.
I made this stupid patch (attached) that include the same test than
gl_cv_func_printf_directive_n in  coreutils sleep usage

[chroot-i486] root:/usr/src/coreutils-8.5$ gl_cv_func_printf_directive_n=no
./configure --prefix=/usr
[chroot-i486] root:/usr/src/coreutils-8.5$ make
[chroot-i486] root:/usr/src/coreutils-8.5$ ./src/sleep; echo $?
./src/sleep: missing operand
Try `./src/sleep --help' for more information.
*** %n in writable segment detected ***
Aborted
134
[chroot-i486] root:/usr/src/coreutils-8.5$ make clean
[chroot-i486] root:/usr/src/coreutils-8.5$ gl_cv_func_printf_directive_n=yes
./configure --prefix=/usr
[chroot-i486] root:/usr/src/coreutils-8.5$ make
[chroot-i486] root:/usr/src/coreutils-8.5$ ./src/sleep; echo $?
./src/sleep: missing operand
Try `./src/sleep --help' for more information.
*** %n in writable segment detected ***
Aborted
134

So result is the same with gl_cv_func_printf_directive_n=no or
gl_cv_func_printf_directive_n=yes.
Am I wrong somewhere?
What is the gain that this test is so written?

Gilles