grep-devel
[Top][All Lists]
Advanced

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

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


From: Jim Meyering
Subject: Re: [Grep-devel] Proposed patch: remove DFA_CASE_FOLD
Date: Wed, 7 Dec 2016 16:18:28 -0800

On Wed, Dec 7, 2016 at 9:05 AM, Paul Eggert <address@hidden> wrote:
> 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.

Good points, all.
Please excuse my hasty objection.



reply via email to

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