bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Gilles Espinasse
Subject: Re: bug#5999: new snapshot available: coreutils-8.4.100-81926
Date: Tue, 27 Apr 2010 07:44:43 +0200

----- Original Message ----- 
From: "Bruno Haible" <address@hidden>
To: "Paolo Bonzini" <address@hidden>
Cc: "Jim Meyering" <address@hidden>; "Gilles Espinasse" <address@hidden>;
<address@hidden>; <address@hidden>
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  <address@hidden>
>             Bruno Haible  <address@hidden>
>
> * 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

Attachment: sleep_writable-format.patch
Description: Binary data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]