Re: position of setting locale-related variables in acgeneral.m4?

[Akim Demaille]

| Hi, autoconfers

Hi!

| I've gotten a report from a user with having locale-related problems
| running the configure script that I supply.  In other words, it works
| fine when running with LC_ALL=C but not in some other locales.  What's
| failing is:
| 
|     expr "x$ac_package" : ".*[^-a-zA-Z0-9_]" >/dev/null &&
|       { echo "configure: error: invalid package name: $ac_package" >&2; exit 
1; }
| 
| Dunno why that would fail in some non-C locale, but the safest thing
| seems to be to always run in a predictable locale and configure does
| that but further down from the argument parsing.  I've tried the
| following simple patch and it seems to work with simple tests.
| Comments?

I'm OK with the patch (but the ChangeLog should be more precise,
stating from where to where you moved the macro invocation, but that's
OK, I'll handle this).

The failure is extremely famous, and there is an incredible amount of
news in gnu.bug.utils about this but in the context of grep.  It is
simply that some locales have more letters in between a and b.  For
instance in French:

/tmp % cat >foo                                                  nostromo 10:36
a
à 
A
b
B
/tmp % LC_ALL=fr_FR sort <foo                                    nostromo 10:37
a
A
à
b
B
/tmp % LC_ALL=fr_FR grep '[a-b]' foo                             nostromo 10:37
a
à
A
b
/tmp % LC_ALL=C sort <foo                                        nostromo 10:38
A
B
a
b
à
/tmp % LC_ALL=C grep '[a-b]' foo                                 nostromo 10:38
a
b

Nevertheless I am surprised that the above test failed.  I'd like to
know how it fails, and what was the --with option he used.

Note that configure is indeed guilty here, the system is right.
Autoconf should not depend upon character intervals, rather it should
list them all.  But that can be delayed to another patch, this one is
fine.