Re: [PATCH] Keep expected behaviour for [a-z] and [A-z] (Bug 23393).

[Carlos O'Donell <carlos@redhat.com>]

On 07/25/2018 06:50 PM, Florian Weimer wrote:
> On 07/25/2018 11:35 PM, Carlos O'Donell wrote:
>> I have committed only the most conservative fix for this issue,
>> which is to deinterlace the lower and upper case ranges.
>> 
>> I think we are too late to commit rational ranges, and we can do
>> that in 2.29 when it opens. Right now I want to remove the blocker
>> that is causing regressions for en_US.UTF-8 scripts that use [a-z],
>> and [A-Z].
> 
> How is this the most conservative fix, relative to glibc 2.27
> upstream?

We have two solutions to fix the regression:

* Revert the entire ISO 14651 udpate.
  - This is 13 commits for just the update.
  - Several more commits for Rafal and Mike's work on locales on top of that.

* Fix the key issue of a-z interleaving with A-Z.

My opinion is that is most conservative to fix the interleaving.

In 2.27 we accepted 297 characters between A-Z.

In 2.28 we accept 2280 characters between A-Z as part of the ISO 14651 update.
 
> [a-z] still matches lots of non-ASCII characters, which it did not
> before.

This is not true, we were already matching 297 characters between A-Z
in 2.27. It has always been the case that we accepted non-ASCII characters
in the range. With the ISO 14651 update the *key* issue was that lowercase
and uppercase were now mixed in collation element ordering, resulting in
surprising matches and failures like the reported xfs test failure where
[a-z] matched "Makefile" and broke their test infrastructure.
 
> When I meant that we left regression-fixing territory, I was talking
> about the locales which had iso14651_t1_common customizations.

OK, so to be clear you think we *should* go forward with rational ranges?

I don't think it's too late, we could commit it tomorrow, it should not
impact machine testing in way.

My v4 fixes all of the locales that either have customizations on
iso14651_t1_common or have their own custom locales. No more locales
remain to be fixed, I tested all of them with tst-fnmatch.input additions
to catch the ones that needed fixing.

Cheers,
Carlos.