Hi, Ingo Schwarze wrote on Thu, Oct 15, 2020 at 05:32:32PM +0200:
> Meanwhile, i heard rumours that the upcoming change in libc that will > cause %n in writeable memory to abort the program will cause some > gnulib ./configure tests to (wrongly) fail, again resulting in > compilation of vasnprintf.c So far, the rumour turned out to be true. On OpenBSD-current, after building a kernel and libc that rejects %n in writeable memory and after rebuilding GNU m4 and GNU bison on top of that, when i run "../configure" in groff/build, i now see this in config.status: configure:9431: checking whether printf supports the 'n' directive configure:9512: result: no gl_cv_func_fprintf_posix=no gl_cv_func_printf_directive_n=no gl_cv_func_printf_enomem=no REPLACE_FPRINTF='1' #define REPLACE_FPRINTF_POSIX 1 The groff build consequently proceeds to build vasnprintf.c. (I certainly don't like it when application software goes out of its way trying to defeat security features of the operating system. By the way, Dave Kemper reported the same effect from his Gentoo Linux system: groff is trying to circumvent system security features there, too. But that's a long-standing effect rather than a regression, so it probably shouldn't hold up the release.) > with %n But this part is not true. At least on OpenBSD (and probably on Gentoo, not sure about other platforms, this is certainly all rather fragile) config.status says: configure:10741: checking whether snprintf returns a byte count as in C99 configure:10843: result: yes configure:10849: checking whether snprintf truncates the result as in C99 configure:10942: result: yes #define HAVE_SNPRINTF_RETVAL_C99 1 #define HAVE_SNPRINTF_TRUNCATION_C99 1 That results in %n not being used by the new version of lib/vasnprintf.c. > and ultimately killing groff at run-time. That part of the rumour isn't true either. A package of groff-current built as described above works for me on OpenBSD-current, not counting two or three minor regressions that i'll inestigate sepaarately because they are clearly unrelated to vasnprintf.c. So i think further deliberation of the vasnprintf.c issue can be postponed until after release. Yours, Ingo