Gilles Espinasse wrote: ... > 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
You should be able to consider this resolved. Once you start using the latest from gnulib, you will no longer see that glibc diagnostic mixed in with configure-output "checking..." messages. > [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? The success or failure of that test contributes to whether a project uses the native vasnprintf (because it passes all tests) or a replacement. See the many conditions in gnulib/m4/vasnprintf-posix.m4.
