Re: fix bug in glibc 2.7 macro implementation of strtok_r.

[Eric Blake]

-----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             address@hidden
-----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-----