On 06/09/2011 11:58 AM, Bruno Haible wrote:
Paolo,
[=e=] to match "e" as well as accented versions like é, è and ê).
That is the one feature that you get with glibc, and that you would
sacrifice when building --with-included-regex.
I agree. It's up to distros to choose, of course.
If you are on the point of sacrificing a glibc feature in many programs,
then IMO you should first talk with the glibc people to see what alternative
they can offer.
No, I'm not! It's not any different from now. Right now, some
distros/people use --with-included-regex and get broken semantics + no
equivalence classes; others use --without-included-regex and get another
kind of broken semantics.
With my proposal, distros/people that use --with-included-regex would
get understandable semantics + no equivalence classes; others will see
no change.
I don't plan to change the default between the two.
It is probably futile to ask Ulrich Drepper to change how [a-z] is interpreted
by default.
I think it would be possible to discuss it civilly with Uli (not on
Bugzilla though). Unfortunately, more glibc development now seems to be
done by someone I shall not name who sports twice the arrogance and half
the knowledge/talent.
But what would gnulib need so as to implement our "desired"
behaviour? As far as I understand, you want to keep the interpretation of
[=e=] in the POSIX + glibc way, but change the interpretation of [a-z]?
That's a different story. If we could implement [=e=] in gnulib code
using glibc extensions, I would be all for that. But even right now,
using gnulib's regex means sacrificing [=e=]. So that's a separate topic.
The only possibility is that with this change more distros may be using
--with-included-regex. That's their choice, not ours.
Then, what do we need from glibc?
- Do we need a RE_RANGES_IGNORE_LOCALES flag, like Arnold proposed?
No, that would be really really bad to have, for the reasons I mentioned
in my original email.
- Do we need an API that allows us to access the collation elements?
(Or is strcoll and wcscoll sufficient?)
No, they're not, and I thought about designing such an API last year,
but in the end decided that locale behavior of regex are irremediably
broken. For example, when you have a collation element, you can match
it using ranges (e.g. [d-i] matches "ch" in Czech; "ch" collates after
"h"), and even apply negation (e.g. [^c-h] matches "ch" too). However
there is no way to anchor your match to the beginning of the collation
element. So "chci" matches both /[c-h]+ci/ and /[^c-h]+ci/. It is
beyond repair, and [=e=] is the only part that can be salvaged.
Paolo
