On OSF/1 5.1, the test "checking whether strtok_r works" succeeds with cc but fails with gcc. Why? config.log shows these errors:
configure:55854: checking whether strtok_r works configure:55894: gcc -std=gnu99 -o conftest -g -O2 -Wall -mieee conftest.c >&5 conftest.c: In function 'main': conftest.c:681: error: stray '\302' in program conftest.c:681: error: stray '\240' in program conftest.c:681: error: stray '\302' in program conftest.c:681: error: stray '\240' in program conftest.c:681: error: stray '\302' in program conftest.c:681: error: stray '\240' in program conftest.c:681: error: stray '\302' in program conftest.c:681: error: stray '\240' in program conftest.c:681: error: stray '\302' in program conftest.c:681: error: stray '\240' in program conftest.c:681: error: stray '\302' in program conftest.c:681: error: stray '\240' in program conftest.c:682: error: stray '\302' in program conftest.c:682: error: stray '\240' in program conftest.c:682: error: stray '\302' in program conftest.c:682: error: stray '\240' in program conftest.c:682: error: stray '\302' in program conftest.c:682: error: stray '\240' in program ... The reason is that UTF-8 encoded non-breaking-space characters crept in on 2009-09-06, in <http://lists.gnu.org/archive/html/bug-gnulib/2009-09/msg00070.html>. In an ISO-8859-1 locale, the patch looks like this: + [[char delimiters[] = "xxxxxxxx"; + Â Â Â Â Â Â char *save_ptr = (char *) 0xd0d0; + Â Â Â Â Â Â strtok_r (delimiters, "x", &save_ptr); + Â Â Â Â Â Â strtok_r (NULL, "x", &save_ptr); + Â Â Â Â Â Â return 0; + ]]) It was my mistake, but I have no idea how this happened. 2010-12-25 Bruno Haible <br...@clisp.org> strtok_r: Fix C syntax error in autoconf macro. * m4/strtok_r.m4 (gl_FUNC_STRTOK_R): Don't use UTF-8 encoded U+00A0 characters in test program. --- m4/strtok_r.m4.orig Sat Dec 25 10:40:00 2010 +++ m4/strtok_r.m4 Sat Dec 25 10:39:43 2010 @@ -1,4 +1,4 @@ -# strtok_r.m4 serial 11 +# strtok_r.m4 serial 12 dnl Copyright (C) 2002-2004, 2006-2007, 2009-2010 Free Software Foundation, dnl Inc. dnl This file is free software; the Free Software Foundation @@ -16,7 +16,7 @@ AC_DEFUN([gl_FUNC_STRTOK_R], if test $ac_cv_func_strtok_r = yes; then dnl glibc 2.7 has a bug in strtok_r that causes a segmentation fault dnl when the second argument to strtok_r is a constant string that has - dnl exactly one byte and compiling with optimization. This bug is, for + dnl exactly one byte and compiling with optimization. This bug is, for dnl example, present in the glibc 2.7-18 package in Debian "lenny". dnl See <http://sources.redhat.com/bugzilla/show_bug.cgi?id=5614>. AC_CACHE_CHECK([whether strtok_r works], [gl_cv_func_strtok_r_works], @@ -32,10 +32,10 @@ AC_DEFUN([gl_FUNC_STRTOK_R], ]], [[static const char dummy[] = "\177\01a"; char delimiters[] = "xxxxxxxx"; - char *save_ptr = (char *) dummy; - strtok_r (delimiters, "x", &save_ptr); - strtok_r (NULL, "x", &save_ptr); - return 0; + char *save_ptr = (char *) dummy; + strtok_r (delimiters, "x", &save_ptr); + strtok_r (NULL, "x", &save_ptr); + return 0; ]]) ], [gl_cv_func_strtok_r_works=yes],
