bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: merging the three forks of dfa.c ?


From: Bruno Haible
Subject: Re: merging the three forks of dfa.c ?
Date: Sun, 1 Feb 2009 23:58:20 +0100
User-agent: KMail/1.9.9

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]