At least in the configure scripts of sys-apps/coreutils-6.10-r2 and sys-devel/m4-1.4.12 (probably there are more packages) an error message is thrown: *** %n in writable segment detected *** They seem to compile and work fine, but this error message is very ugly as in a bash it can not be caught by piping stdout or stderr. The code snippet from config.log is in both cases: | #include <stdio.h> | #include <string.h> | static char fmtstring[10]; | static char buf[100]; | 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; | } Probably this is just the case that is described in the C comment: glibc was compiled with gcc 4.3.3.
Created attachment 180602 [details] /var/tmp/portage/sys-devel/m4-1.4.12/work/m4-1.4.12/config.log config.log from interrupted (Ctrl+C) configure script
Created attachment 180603 [details] /var/tmp/portage/sys-apps/coreutils-6.12-r2/work/coreutils-6.12/config.log config.log from interrupted (Ctrl+C) configure script
From the posts on mailing list, seems it was an intended change in gcc 4.3.3 (it's in one of the patches). Though, for anybody NOT tracking that list, it was a not really pleasant surprise.
i would say it's working exactly as advertised.
yep, not a glibc bug, nor gcc. as Ryan says, everything is operating as designed.
In any case: I do not think it is a good idea to have random messages on bash that can not be controlled. So if gcc and glibc are working as they should - maybe I should ask upstream what they think about this. But who would be the right one? autoconf? automake? coreutils/m4? gcc? glibc?
glibc itself opens up /dev/tty and writes the error/abort message to it thus bypassing stderr/stdout redirection. it might be ugly, but it was done on purpose, and the glibc guys arent about to change it.
So I will ask autconf/automake (upstream) to change their test case with sprintf.
except the test case in question is testing for this exact behavior. it needs to know if using %n in a writable segment will fail.
When bug 278895 is fixed, this should no longer be an issue since we'll use a pty device for /dev/tty.
*** Bug 408715 has been marked as a duplicate of this bug. ***