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

[Baptiste Daroussin]

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.

---
Bapt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/svn-src-all/attachments/20151110/3078dbbd/attachment.bin>