Gilles Espinasse wrote:
...
>> 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
Thanks, but you should not have to do that.
Here's a patch to make that diagnostic go where it belongs
for all gnulib-using projects:
Bruno, I could have factored out the 4-line snippet into its own
macro instead of writing it twice, but it didn't seem worthwhile...
Ok to commit?
>From e793f628df456cece652c3e3b296a113ced676a9 Mon Sep 17 00:00:00 2001
From: Jim Meyering <meyer...@redhat.com>
Date: Mon, 26 Apr 2010 08:38:15 +0200
Subject: [PATCH] printf: redirect configure time diag, "%n in writable segment
detected"
* m4/printf.m4 (gl_PRINTF_DIRECTIVE_N): Arrange for glibc's "%n in
writable segment detected" diagnostic to be written to stderr, where
we can redirect it.
(gl_SNPRINTF_DIRECTIVE_N): Likewise.
Prompted by an exchange with Gilles Espinasse.
---
ChangeLog | 9 +++++++++
m4/printf.m4 | 8 ++++++++
2 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 9208e2f..f39450d 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,12 @@
+2010-04-26 Jim Meyering <meyer...@redhat.com>
+
+ printf: redirect configure time diag, "%n in writable segment detected"
+ * m4/printf.m4 (gl_PRINTF_DIRECTIVE_N): Arrange for glibc's "%n in
+ writable segment detected" diagnostic to be written to stderr, where
+ we can redirect it.
+ (gl_SNPRINTF_DIRECTIVE_N): Likewise.
+ Prompted by an exchange with Gilles Espinasse.
+
2010-04-25 Bruno Haible <br...@clisp.org>
ptsname: Fix misuse of ttyname_r.
diff --git a/m4/printf.m4 b/m4/printf.m4
index ebca536..12649b5 100644
--- a/m4/printf.m4
+++ b/m4/printf.m4
@@ -594,6 +594,10 @@ AC_DEFUN([gl_PRINTF_DIRECTIVE_N],
[
AC_REQUIRE([AC_PROG_CC])
AC_REQUIRE([AC_CANONICAL_HOST]) dnl for cross-compiles
+ # Tell glibc to write its "%n in writable segment detected" diagnostic
+ # to stderr, not to the tty, so that we can redirect it.
+ LIBC_FATAL_STDERR_=1
+ export LIBC_FATAL_STDERR_
AC_CACHE_CHECK([whether printf supports the 'n' directive],
[gl_cv_func_printf_directive_n],
[
@@ -1162,6 +1166,10 @@ AC_DEFUN([gl_SNPRINTF_DIRECTIVE_N],
[
AC_REQUIRE([AC_PROG_CC])
AC_REQUIRE([AC_CANONICAL_HOST]) dnl for cross-compiles
+ # Tell glibc to write its "%n in writable segment detected" diagnostic
+ # to stderr, not to the tty, so that we can redirect it.
+ LIBC_FATAL_STDERR_=1
+ export LIBC_FATAL_STDERR_
AC_CACHE_CHECK([whether snprintf fully supports the 'n' directive],
[gl_cv_func_snprintf_directive_n],
[
--
1.7.1.rc2.340.g38e7f
