Re: [bug-grep] dfa.c sync with gawk, progress report

[Aharon Robbins]

>    I'd like to catch up with gawk/dfa.c, so that we can serve as
> a primary source of dfa for both.  After the i18n patch by Isamu
> Hasegawa, I checked in a few simple changes imported from gawk.
>
> The following patches remain in the queue:
>
> 1) dfa-newline.patch -- adds ability to match embedded newlines;
>    grep doesn't use it but gawk needs it.
> 2) dfa_backslash_s.patch  -- support \s and \S
> 3) dfa-arnold-icase.patch
> 4) http://lists.gnu.org/archive/html/bug-gnu-utils/2004-11/msg00096.html
> 5) http://lists.gnu.org/archive/html/bug-gnu-utils/2004-11/msg00098.html
> 6) http://lists.gnu.org/archive/html/bug-gnu-utils/2004-11/msg00097.html
>
> The former three patches are attched to this mail.
> The last three are URLs to gawk bug reports, but I believe they apply to
> grep, too.  The fixes submitted there are attached to this mail as a
> combined patch, named dfa-deb-jp.patch .
>
> When we process these, we are in sync with gawk's dfa.c.

I have verified that the version Stepan is working towards work OK
with gawk.

> 1) Matching enbedded newlines is a need for awk.  We could #ifdef it if
> it would worth the work.

This should be timed first.  I suspect that (a) there's little or
no impact on performance, and (b) that ifdefing will lead to much
greater code complexity than is really necessary.

> I think the interface is probably the same as it was in dfa.c in
> grep-2.4.2 and older.

Yes, that's how I restored the newline matching facility.

> I think we could modify it.  Noone wants the
> COUNT parameter, for example.

Just as a point of information, it will be easier for me to keep in
sync if you apply all the above patches into CVS first, and then
go from there with any new surgery.

I appreciate the efforts to be concerned about gawk's needs as well.

Thanks,

Arnold