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" -- http://ache.vniz.net/
signature.asc
Description: OpenPGP digital signature