GNU bug report logs - #5999
new snapshot available: coreutils-8.4.100-81926

Previous Next

Full log

Message #24 received at 5999-done <at> debbugs.gnu.org (full text, mbox):

From: "Gilles Espinasse" <g.esp <at> free.fr>
To: "Bruno Haible" <bruno <at> clisp.org>,
	"Paolo Bonzini" <bonzini <at> gnu.org>
Cc: 5999-done <at> debbugs.gnu.org, bug-gnulib <at> gnu.org,
	Jim Meyering <jim <at> meyering.net>
Subject: Re: bug#5999: new snapshot available: coreutils-8.4.100-81926
Date: Tue, 27 Apr 2010 07:44:43 +0200

[Message part 1 (text/plain, inline)]

----- Original Message ----- 
From: "Bruno Haible" <bruno <at> clisp.org>
To: "Paolo Bonzini" <bonzini <at> gnu.org>
Cc: "Jim Meyering" <jim <at> meyering.net>; "Gilles Espinasse" <g.esp <at> free.fr>;
<5999-done <at> debbugs.gnu.org>; <bug-gnulib <at> gnu.org>
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  <jim <at> meyering.net>
>             Bruno Haible  <bruno <at> clisp.org>
>
> * 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

[sleep_writable-format.patch (application/octet-stream, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.