Replacing libgnuregex
Kyle Evans
kevans91 at ksu.edu
Sat Apr 15 16:31:31 UTC 2017
On Apr 15, 2017 11:18 AM, "Baptiste Daroussin" <bapt at freebsd.org> wrote:
On Sat, Apr 15, 2017 at 01:02:42AM -0500, Kyle Evans wrote:
> An amended version of this patch can be found here:
> https://files.kyle-evans.net/freebsd/libc-gnuext-2.diff
>
> This one introduces a REG_POSIX flag for regcomp(3) that removes the GNU
> extension for a more POSIX conformant implementation along with an
> amendment to regex.3 to document said flag.
>
> Instead of removing the tests that don't fail like they should under GNU
> extensions, I've restored them and added a 'P' flag to specify REG_POSIX
> and marked the failing tests as such to clearly denote that they require a
> more strict implementation.
>
> Thanks,
>
Thanks for working on this
Just to follow up on this:
Have you tested the results with the AT&T testsuite for regex?
You can find it at least in the dragonfly source tree:
https://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/abc
e74f49c2c19b069958a0b48de0a9987d14e35
Or online I don't remember where :)
another approach would be to import libtre + extension in our libc (like it
was
done on dragonfly - it was actually a freebsd project that stalled)
Best regards,
Bapt
Yup, we also have a copy of the AT&T test suite in tree
(contrib/netbsd-tests/lib/libc/regex/data/att). It passed that, the other
NetBSD tests, and I also ran the NetBSD sed and the gsed test suites using
a script provided by pfg@ to ensure no trivial breakage.
Has TRE improved over the years? It seems like we had a version around 2011
or so for bsdgrep that was quite rough. I'm not sure if that was heavily
modified or just an early infancy state.
I think in either case, we might consider throwing errors for the bogus
escape sequences (anything that's not \<, \>, and backrefs for BREs) as an
intermediate to stop *that* behavior, because that's going to be
problematic for many approaches.
More information about the freebsd-hackers
mailing list