Replacing libgnuregex

[Kyle Evans]

On Sun, Apr 16, 2017 at 6:37 PM, Kyle Evans <kevans91 at ksu.edu> wrote:

> On Sun, Apr 16, 2017 at 3:43 PM, Joerg Sonnenberger <joerg at bec.de> wrote:
>
>> On Sun, Apr 16, 2017 at 03:47:56PM +0200, Jilles Tjoelker wrote:
>> > On Tue, Apr 11, 2017 at 03:20:58PM -0500, Kyle Evans wrote:
>> > > On the other hand, I think I could fairly easily implement most of
>> these
>> > > into libc/regex. Here's a summary of what this option entails adding
>> to
>> > > libc/regex, from what I've found:
>> >
>> > > [snip]
>> > > * Add backreferences (\1 through \9) to EREs
>> > > [snip]
>> >
>> > Adding this enforces that EREs, like BREs, may sometimes require
>> > exponential time to match. I would prefer to avoid that.
>>
>> The Spencer RE doesn't need backreferences to be exponential, but I
>> certainly agree that adding support for them makes it more difficult to
>> change to a better RE implementation later.
>>
>
> Are there plans in progress to replace this at some point?
>
> If not, would it be acceptable to lib'ify what we have now, ensure the
> libc bits remain strict POSIX (-DPOSIX_STRICT to exclude any GNU cruft, not
> just disabled at runtime), and have the libregex version include GNU
> extensions? This seems likes a reasonable approach to make sure
> expectations of libc remain as they are now while also not introducing more
> maintenance overhead, assuming there are no immediate plans to replace the
> regex implementation.
>

To be perfectly clear, what I mean by "lib'ify" is generally this patch:
https://files.kyle-evans.net/freebsd/libregex.diff

Changes made to the source to make non-libc build work properly, tested
with the netbsd-tests on libc as well as libregex. Further changes to
include GNU extensions or whatnot would be conditionally compiled into
libregex, and libregex may be excluded by adrian@ on his MIPS builds. =)

bsdgrep(1) may be adjusted to link libregex (if it's being built) to
maintain GNU extensions going forward, but I suspect that change would be
after the dust settles on the bsdgrep stuff going on right now and if I can
find a nice middle-ground to get libgnuregex replaced.