On 10.11.2015 19:19, Andrey Chernov wrote: > On 10.11.2015 19:12, Baptiste Daroussin wrote: >> On Tue, Nov 10, 2015 at 07:07:26PM +0300, Andrey Chernov wrote: >>> On 10.11.2015 16:36, Baptiste Daroussin wrote: >>>> On Tue, Nov 10, 2015 at 04:20:38PM +0300, Andrey Chernov wrote: >>>>> On 10.11.2015 16:04, Baptiste Daroussin wrote: >>>>>> On Tue, Nov 10, 2015 at 03:48:52PM +0300, Andrey Chernov wrote: >>>>>>> On 10.11.2015 11:11, Baptiste Daroussin wrote: >>>>>>>> Author: bapt >>>>>>>> Date: Tue Nov 10 08:11:27 2015 >>>>>>>> New Revision: 290637 >>>>>>>> URL: https://svnweb.freebsd.org/changeset/base/290637 >>>>>>>> >>>>>>>> Log: >>>>>>>> return "US-ASCII" instead of "POSIX" for "C" and "POSIX" locales >>>>>>>> as it used to be in previous version of the locales. Returning >>>>>>>> "POSIX" has too many fallouts. >>>>>>> >>>>>>> You can return "ANSI_X3.4-1968" (another name of "US-ASCII") to be >>>>>>> different with real US-ASCII. It is what glibc returns for C/POSIX >>>>>>> locale and most ports expected, being linux-oriented. >>>>>>> >>>>>> I thought about it, but in the end it is probably safer for now that >>>>>> nl_langinfo >>>>>> return US-ASCII as it did in the past, to reduce breakage with FreeBSD >>>>>> only code >>>>>> that maybe be existing ou there. >>>>> >>>>> All FreeBSD code I know never check locale this way. IMHO probability of >>>>> potential danger to meet some linux-oriented port with this check is >>>>> much much higher than to meet similar FreeBSD only code in the wild. In >>>>> any case, changing collate order from A-Za-z to aA-zZ we do just now >>>>> have much higher probability to break unknown FreeBSD only code, so one >>>>> breaking change can go with other one together. >>>>> >>>> That is true, except that the new collation thing is invalidated as soon >>>> as you >>>> set LC_COLLATE=C which bring your back to A-Za-z. So you have a workaround >>>> while >>>> changing the return value of nl_langinfo() is not workaroundable. >>> >>> Well, forget my improper comparison with collate and see this bug in >>> action right now, in our port tcl8.6.4/unix/tclUnixInit.c: >>> >>> See localeTable and comment above it, there is internal "ansi_x3.4-1968" >>> (i.e. POSIX locale), internal "ascii" and even no alias for our >>> "us-ascii" at all. >>> >>> It gets info through nl_langinfo(CODESET), lowercased. I.e. not using >>> "ANSI_X3.4-1968" breaks all tcl ports right now, this is more essential >>> than hypothetical private FreeBSD only code no one see. >> >> That one is a valid point, that also means that is is broken right now on >> FreeBSD 10 and below? > > Yes. It can't map our C locale to the some of internal ones and falls > back to TCL_DEFAULT_ENCODING "iso8859-1" >
BTW, for pure ASCII locale readded we should return "ASCII" instead of "US-ASCII". I search lots of Linux code and see many checks for "ASCII" and no checks for "US-ASCII" (like in tcl too). -- http://ache.vniz.net/
signature.asc
Description: OpenPGP digital signature
