Re: grep: fix multibyte regex handling under macOS (1819ad327b7a1f19540a819813b70a0e8a7f798f)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Feb 03, 2023 at 10:56:53PM +0100, Ævar Arnfjörð Bjarmason wrote:

> > I don't have a strong opinion either way. The main concern I'd have is
> > handling dependencies. I like pcre a lot, but I'm not sure that I would
> > want building Git to require pcre on every platform. If there's an
> > engine we can ship as a vendored dependency that builds everywhere, that
> > helps.
> 
> We can just make that fallback engine be PCRE. I submitted patches a
> while ago to include a minimal version of it in compat/pcre, as we seem
> to have some allergy to external dependencies:
> https://lore.kernel.org/git/20170511175115.648-1-avarab@xxxxxxxxx/
> 
> It's ~80k lines instead of compat/regex's ~15k, but it's actually
> maintained, and would be much easier to upgrade.

I'm OK with that if we really think that libpcre will build without
problems on every platform that Git does. I don't know if we have any
data there. Obviously libpcre builds lots of places, but will we have
problems on obscure platforms like NonStop? Part of me wants to not
care, but if the value here is saying "the regex engine is always going
to be X", then there is not much point in saying "the regex engine is
usually X, but you can't rely on it because sometimes it's not".

"Usually" is enough for helping users quality of life (if we help 99% of
users, that is good). It isn't enough for making assumptions in the code
(like using constructs in userdiff regexes that would break horribly on
the other 1% of platforms).

-Peff



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux