-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 According to Ben Pfaff on 8/31/2009 6:56 AM: > The reason that I'm submitting it is > that I discovered this glibc bug myself, and it's been bothering > me ever since that gnulib doesn't detect and work around it, > because it seems very easy to trigger.
Seems like a worthwhile patch to me. However, since it appears that is only triggered based on your choice of -O, are we guaranteed that your .m4 snippet will always flush it out, even if the user later passes a different -O setting via 'make CFLAGS=...'? > +++ b/doc/posix-functions/strtok_r.texi > @@ -9,6 +9,9 @@ Gnulib module: strtok_r > Portability problems fixed by Gnulib: > @itemize > @item > +The macro version of this function segfaults on some inputs on some > +versions of glibc. In the bug report, Ulrich says it is fixed upstream; can we list which glibc version that will be (ie. 2.11)? > + if test $gl_cv_buggy_strtok_r_macro = yes; then > + HAVE_BUGGY_STRTOK_R_MACRO=1 Naming convention - I'm wondering if it would be better to use the name FUNC_STRTOK_R_MACRO_BROKEN. Using category (FUNC), name (STRTOK_R), then characteristic (MACRO_BROKEN) is the form suggested by the autoconf manual. - -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqdBREACgkQ84KuGfSFAYBh8QCgnk5/l+2vjGJKQLp0X1cHnl+M 1BwAoLbQkP+Eu6GFL6nJn3z8moOU+D6w =eYcQ -----END PGP SIGNATURE-----
