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

Previous Next

Full log

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

From: "Gilles Espinasse" <g.esp <at> free.fr>
To: "Jim Meyering" <jim <at> meyering.net>
Cc: 5999-done <at> debbugs.gnu.org
Subject: Re: bug#5999: new snapshot available: coreutils-8.4.100-81926
Date: Sat, 24 Apr 2010 08:59:28 +0200

----- Original Message ----- 
From: "Jim Meyering" <jim <at> meyering.net>
To: "Gilles Espinasse" <g.esp <at> free.fr>
Cc: <5999-done <at> debbugs.gnu.org>
Sent: Friday, April 23, 2010 9:15 AM
Subject: Re: bug#5999: new snapshot available: coreutils-8.4.100-81926


> Gilles Espinasse wrote:
> ...
> > I forgot to report the spurious configure test
> > util-linux-ng  [     2.17.2 ] [         0 ] [ DONE ]
> > e2fsprogs     [    1.41.11 ] [         0 ] [ DONE ]
> > coreutils       [ 8.4..81926 ]*** %n in writable segment detected ***
>
> I'm pretty sure that output comes from the C library writing to /dev/tty
> during a "run test".
>
> > To hide that, we use
> >  gl_cv_func_printf_directive_n=no ./configure
> >
> > We use gl_cv_func_printf_directive_n=no in gzip and m4 too where the
same
> > problem happen.
>
> Priming the cache with a value saying "the %n directive is mishandled"
> does indeed skip the test and avoid the warning-to-tty, but it may make
> the resulting tools unnecessarily avoid using your C library's functions.
> Why did you choose "no" rather than "yes"?  At least on glibc-based
> systems, %n does work the way it's supposed to.
>
Thank for the suggestion.
That's not me wich do that change.
I suppose it was set to the value resulting of the test.
I checked to have gl_cv_func_printf_directive_n=no in config.log when using
only ./configure

As the comment in the test program say
| int main ()
| {
|   int count = -1;
|   /* Copy the format string.  Some systems (glibc with _FORTIFY_SOURCE=2)
|      support %n in format strings in read-only memory but not in writable
|      memory.  */
|   strcpy (fmtstring, "%d %n");
|   if (sprintf (buf, fmtstring, 123, &count, 33, 44, 55) < 0
|       || strcmp (buf, "123 ") != 0
|       || count != 4)
|     return 1;
|   return 0;
| }
configure:19018: result: no

We compile now glibc with _FORTIFY_SOURCE=2 and that's the reason of the
failure in the test and why we have the spurious message.
If the test is right, to my understanding, we should not set
gl_cv_func_printf_directive_n=yes

I will change to LIBC_FATAL_STDERR_=1 ./configure so the spurious message is
redirected to stderr. Probably the advice to set LIBC_FATAL_STDERR_=1 to
avoid the spurious character of the message should be added to the test
program.

http://sourceware.org/bugzilla/show_bug.cgi?id=9854

Gilles

Previous Next

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