On 09/06/2018 12:39 PM, Aharon Robbins wrote:
In article <mailman.444.1536243821.1284.bug-b...@gnu.org>,
Eric Blake <ebl...@redhat.com> wrote:
But bash could be taught to convert any regex that contains a range with
both endpoints ASCII into a different bracket expression before handing
things over to regcomp(). That is, if the user is matching against
[a-d], bash hands [abcd] to regcomp() instead. You don't need a flag in
regcomp() to get RRI, just merely some pre-processing (and often memory
allocation, as the expansion of a range into a non-range tends to
require more characters).
This is easy and inexpensive for ASCII only. Full RRI does the
same thing for wide character sets as well, though, and there
the possibility for using very large amounts of memory makes the
rewrite-the-range idea less palatable.
Indeed. But the bash option is named 'globasciiranges', and I find far
more use in having ranges with both endpoints in single-byte ASCII
behaving sanely than I do for ranges with one or more ends resulting in
a multibyte character (by the time my regex involves multibyte
characters, I am already admitting that I am in locale-dependent
territory, and RRI may no longer be the best action anyway). That is,
RRI makes the most sense when dealing with ASCII characters (< 128) in
the first place, and that's a reasonable stopgap for immediate
implementation, even if we don't get full RRI across all of Unicode
(assuming that such might later become available via a new regcomp() flag).
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
