Compatibility between GNU and Git grep -P

[Paul Eggert]

In <https://lists.gnu.org/r/grep-devel/2023-04/msg00017.html> Carlo 
Marcelo Arenas Belón wrote:

> After using this for a while think the following will be better suited
> for a release because:
>
> * the unreleased PCRE2 code is still changing and is unlikely to be released
>    for a couple of months.
> * the current way to configure PCRE2 make it difficult to link with the
>    unreleased code (this might be an independent bug), but it is likely that
>    the wrong headers might be used by mistake.
> * the tests and documentation were not completely accurate.

Thanks for looking into this. I'm concerned about the resulting patches, 
though, because I see recent activity in on the Git grep -P side here:

https://lore.kernel.org/git/xmqqzgaf2zpt.fsf@gitster.g/

Bleeding-edge (i.e., "master") GNU grep uses PCRE2_UCP | 
PCRE2_EXTRA_ASCII_BSD with unreleased PCRE2 (which introduces 
PCRE2_EXTRA_ASCII_BSD), and it uses neither flag with the current PCRE2 
release. You're proposing to change GNU grep to never use either flag, 
regardless of PCRE2 release.

In contrast, bleeding-edge (i.e., "next") Git grep -P always uses 
PCRE2_UCP and never uses PCRE2_EXTRA_ASCII_BSD. I.e., it disagrees with 
GNU grep regardless of whether your proposed changes were adopted.

Given Jim's strong desire that \d should match only ASCII digits, I 
doubt whether GNU grep will simply use PCRE2_UCP without 
PCRE2_EXTRA_ASCII_BSD.

If we want the two grep -P's to stay compatible, I see two ways forward:

1. Leave GNU grep alone and modify Git grep to behave like GNU grep (see 
attached patch to Git).

2. Adopt your proposed change to GNU grep, and revert the recent change 
to Git grep so that it never uses PCRE2_UCP.

Either way, we should see what the Git folks say about this.

0001-grep-be-compatible-with-GNU-grep-P.patch
Description: Text Data