[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: update to latest gnulib, with its new dfa API
From: |
Jim Meyering |
Subject: |
Re: update to latest gnulib, with its new dfa API |
Date: |
Tue, 20 Dec 2016 03:28:54 -0800 |
On Tue, Dec 20, 2016 at 3:27 AM, Jim Meyering <address@hidden> wrote:
> On Mon, Dec 19, 2016 at 2:45 PM, Norihiro Tanaka <address@hidden> wrote:
>>
>> On Mon, 19 Dec 2016 03:02:18 -0800
>> Jim Meyering <address@hidden> wrote:
>>
>>> On Sun, Dec 18, 2016 at 2:45 PM, Norihiro Tanaka <address@hidden> wrote:
>>> >
>>> > On Sun, 18 Dec 2016 11:19:04 -0800
>>> > Jim Meyering <address@hidden> wrote:
>>> >
>>> >> I expect to push this tomorrow, and will make a new (final?) snapshot
>>> >> then, too:
>>> >
>>> > If RE_ICASE is not defined as regex library is too old, it does not work.
>>> > It seems that sed supports it still.
>>>
>>> Hi Norihiro,
>>> Thanks for the feedback. Can you point to a specific type of system on
>>> which sed (with this change) fails to build?
>>
>> No, but I seem that sed leaves support for glibc 2.2 or prior and does
>> not assume that RE_ICASE macro is defined always.
>>
>> Now if you hope to remove it, I think "#ifdef RE_ICASE" should be
>> removed.
>
> Thanks. Removing that #ifdef is a good idea, and I've done it in the attached.
> I've left the following "#ifdef RE_NO_SUB" because it is merely an
> optimization, and I did not look
The above sentence can be ignored.
I *did* remove the RE_NO_SUB #ifdef, too.
> Any glibc-based system that is old enough to lack an RE_ICASE
> definition will also be so old that it will fail the configure-time
> checks for known glibc regex bugs, and that will provoke the use of
> the included replacement regex functions. So there should be no
> problem here. By the same argument, I have also removed the "#ifdef
> RE_NO_SUB". That symbol was added to glibc back in 2004.