[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [SCM] GNU Autoconf source repository branch, master, updated. v2.65-

From: Eric Blake
Subject: Re: [SCM] GNU Autoconf source repository branch, master, updated. v2.65-35-ga2889ee
Date: Wed, 03 Feb 2010 06:19:13 -0700
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20090812 Thunderbird/ Mnenhy/

According to Ralf Wildenhues on 2/1/2010 11:44 AM:
> * Ralf Wildenhues wrote on Sat, Jan 30, 2010 at 12:45:33AM CET:
>> Current Cygwin fails the test with or without the patch below, but for
>> another reason:
>> +allowed-chars Zardos differ: char 168, line 2
>> I'm not sure whether it is a regression.  I've tried to debug it; it
>> looks like an issue in Cygwin sed or the shell.  The config.status
>> script in that test directory looks weird: the text which is to be
>> substituted for @zardoz@ is mangled in a way that part of the last line
>> of the string also appears on an earlier line.  I fail to see any
>> connection with newline encoding here, however.
> It's a locale issue.  configure scripts default their environment to C
> locale, but C doesn't have to mean ASCII.  On my Cygwin, C means UTF-8.
> I suppose though that's just because Cygwin changed recently.  Setting
> LC_ALL=C.ASCII makes the test pass.

I need to look into this further, when I can get some spare time.  ANY
test that assumes that bytes >= 128 can be used as valid characters is
inherently non-portable.  There's a difference between byte processing
(which the C locale guarantees for all bytes) and character processing
(which is only valid on characters, but the set of valid characters in the
C locale is allowed to be implementation-dependent).

> Now, I'm not sure what that means for real-life configure scripts.
> IOW, should _AS_SHELL_SANITIZE be fixed, or only this torture test?
> Then, is C.ASCII even a portable setting for LC_ALL (and LANGUAGE)?

C.ASCII is implementation-specific - cygwin has it, but it is not mandated
by any standards.  I don't think _AS_SHELL_SANITIZE is broken (if you are
portably coding for the C locale, then you should NOT be passing 8-bit
bytes through any text-based tools).  But we DO need to add some warnings
to the autoconf manual, and fix this particular test to either try
alternate locales, or skip 8-bit bytes, in the presence of a multibyte C
locale (since POSIX _does_ allow a multibyte C locale).

Don't work too hard, make some time for fun as well!

Eric Blake             address@hidden

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]