Re: merging the three forks of dfa.c ?

[Aharon Robbins]

Bruno,

Hi. This all sounds fine.  I really appreciate your taking this on.

If you are very Strong In The Force, there are also bugs in dfa.c
that "someone" should eventually tackle.  The biggest has to do with
the handling of x{0}.

If not, that's OK too - what you're doing is a definite step forward.

Much thanks!

Arnold

> From: Bruno Haible <address@hidden>
> To: Aharon Robbins <address@hidden>
> Subject: Re: merging the three forks of dfa.c ?
> Date: Sun, 1 Feb 2009 23:58:20 +0100
> Cc: address@hidden, address@hidden
>
> Hi Aharon, Tony,
>
> Thanks for your cooperation. Especially, thanks for mentioning your 
> requirements
> up-front.
>
> > 1. The functionality must remain the same. In particular, at some point in 
> > between
> >    grep 2.4 and grep 2.5, someone removed the ability of the grep dfa to 
> > match
> >    embedded newlines. Gawk requires this.
> > 
> >    I managed, by V E R Y  C A R E F U L hand work to merge the 
> > functionality back
> >    into the gawk dfa from grep 2.4, but it wasn't fun.
> > 
> >    I can tolerate a _reasonable_ change to the calling interface if that 
> > will
> >    make life easier for grep and gettext, but I cannot lose the 
> > functionality.
>
> I will add a unit test to the module, in order to guarantee that this 
> functionality
> will not be destroyed, by whoever makes changes to the module after me.
>
> > 2. The gnulib grep should remain a standalone feature; it cannot start 
> > depending
> >    upon other gnulib features, or I just won't bother.
>
> OK, I'll avoid extra includes in that file, or otherwise mark them with
> #if !defined GAWK.
>
> But I'll add a dependency to the 'mbrtowc' module. This will instruct 
> <config.h>
> and <wchar.h> to provide a correct mbrtowc() function. The dfa.c code uses
> mbrtowc, and the native mbrtowc on AIX, Tru64, Solaris, HP-UX is buggy:
>   
> <http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=doc/posix-functions/mbrtowc.texi;h=df8c59b3dece841da4ecc86a39380695d890b612;hb=HEAD>
> (Unless an analysis shows that dfa.c is immune to these bugs.)
> This does not change the source code that you get from the gnulib source
> repository. If someday you start using gnulib-tool, you can also ignore
> such a dependency by using the option '--avoid=mbrtowc'.
>
> >    Every time I've looked 
> >    at pulling in a module from gnulib, I find that it ends up needing some
> >    rather large transitive closure of other modules, and I don't want to 
> > have
> >    to deal with that.
>
> This is understandable if you proceed by manually copying source code from
> gnulib. With gnulib-tool, things are so much more comfortable that developers
> don't worry any more about additional modules, if they don't lead to more
> code in the executables. Many modules compile to no code at all on glibc
> systems; that's by design.
>
> > I didn't know that dfa was used in gettext. What version of the grep dfa did
> > you start with?
>
> I started with dfa.c from grep 2.5.1. But since you now say that in grep 2.4
> it had features that were subsequently lost, I'll look at this more closely.
> Thanks for the heads-up!
>
> Bruno
>