emacs-devel
[Top][All Lists]
Advanced

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

Re: Regular expression libraries


From: Clément Pit--Claudel
Subject: Re: Regular expression libraries
Date: Fri, 16 Dec 2016 09:54:35 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1

On 2016-12-16 02:20, Paul Eggert wrote:
> Andreas Schwab wrote:
>>> Another library is in that list:
>>> 
>>> - The GNU C library, which ordinarily uses a DFA but which uses 
>>> backtracking if needed.
>> 
>> But it doesn't support a gap.
> 
> True, but none of the others do either. Only the old glibc code
> (which survives only in Emacs now) does that, as far as I know.

Wait, now I'm confused.  The master branch of glibc *does* include the 
following in regex.h:

extern int __re_search_2
  (struct re_pattern_buffer *buffer, const char *string1,
   int length1, const char *string2, int length2,
   int start, int range, struct re_registers *regs, int stop);

… but the implementation just allocates a large buffer and concatenates both 
strings?

Also, one naive question: the code does this:

    int len = length1 + length2;
    char *s = NULL;

    if (BE (length1 < 0 || length2 < 0 || stop < 0 || len < length1, 0))
      return -2;

According to the git history, the last check (len < length1) was added to 
"avoid overflow in computing sum of lengths". But I thought int overflow was 
undefined behaviour, so why does the len < length1 check make sense?

Thanks!
Clément.

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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