Re: [Grep-devel] Proposed patch: remove DFA_CASE_FOLD

[Paul Eggert]

address@hidden wrote:
> > This change would enable a small simplification in each definition of
> > "dfaopts." However, it does that at the cost of changing the public
> > API of the dfa module and making it dependent on the regex one. I.e.,
> > it would change the value of DFA_EOL_NUL (I would object even if this
> > value were left unchanged)
> So insert a DFA_UNUSED_1 value there. OK with me.

Currently the DFA API require the regex API, and the DFA code uses reg_syntax_t 
and a bunch of its values (RE_CHAR_CLASSES, RE_BACKSLASH_ESCAPE_IN_LISTS, etc.). 
If we were to completely decouple the DFA code from regex.h we'd have to 
reinvent all those wheels, which sounds like a nonstarter. So if I'm right, the 
DFA API will continue to depend on the regex API.

Given all that, I'm puzzled as to why there is a DFA_CASE_FOLD. Surely it 
doesn't make sense to have the DFA_CASE_FOLD bit disagree with the RE_ICASE bit, 
so why give applications the option?

I don't see why changing the public API would be a problem. Any application that 
uses dfa.c must set DFA_CASE_FOLD to be consistent with RE_ICASE (otherwise, the 
code doesn't work anyway). Gnulib is not like an ordinary library; API and ABI 
changes are OK in Gnulib, as long as we put something in NEWS. If someone uses a 
new dfa.h (with Arnold's change) but forgets to update their app accordingly, 
they'll get a compile-time error that is obvious and easy to fix. That's all we 
need for Gnulib.

This reminds me of other unfinished business we have, namely, reworking 
dfasyntax so that DFAs can be reused/restarted more efficiently.  I'll see if I 
can squeeze some time free to look into that again. This will be another API change.