sed-devel
[Top][All Lists]
Advanced

[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.



reply via email to

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