svn commit: r290637 - head/lib/libc/locale

[Andrey Chernov]

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/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/svn-src-all/attachments/20151110/64027365/attachment.bin>