bugGNU nano - Bugs: bug #53726, regcomp() sputters when a regex...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #53726: regcomp() sputters when a regex starts with a character class

Submitter:  Benno Schulenberg <bens>
Submitted:  Mon 23 Apr 2018 06:18:22 PM UTC
   
 
Severity:  2 - Minor Status:  Invalid
Assigned to:  None Open/Closed:  Closed

Sat 16 May 2020 10:29:00 AM UTC, comment #3: 

The errno gets set in re_compile_fastmap_iter() in lib/regcomp.c when building some kind of table for the first byte of the expression.  It gets set when __mbrtowc() gets called (around line 384, shortly after "mbs;") with byte values 0x80 to 0xC1.  There is no error here -- the errno just gets set because bytes 0x80 to 0xC1 are not valid starter bytes.

Anyway, 'man 3 errno' says: "a function that succeeds is allowed to change errno".  So... regcomp() setting errno to 84 for certain regexes (but not returning an error code)  is not an error.

Benno Schulenberg <bens>
Group administrator
Sun 18 Aug 2019 11:37:45 AM UTC, comment #2: 

It was just setting errno -- otherwise most syntaxes would be broken.

Here it sets errno (always 84) also for a simple [A-Z] range.

Benno Schulenberg <bens>
Group administrator
Sun 18 Aug 2019 12:08:15 AM UTC, comment #1: 

Was regcomp failing or just setting errno?

When using the attached patch with or without gnulib's regcomp (https://savannah.gnu.org/bugs/?56766), those cases are successful but errno is 84. So something inside regcomp generated an error, which could cause a slowdown.

It also happens for "[0-9]" and other sets with 0-9, but not all sets with 0-9.

(file #47360)

Brand Huntsman <brand>
Mon 23 Apr 2018 06:18:22 PM UTC, original submission:  

After sprinkling a bunch of nperror() calls over the startup code of nano, it results that regcomp() returns an errno that corresponds to "Invalid or incomplete multibyte or wide character".

This error can be traced back to the first color command in syntax/default.nanorc:

  color cyan "^[[:space:]]*#.*"

Reducing the regex to just "[[:space:]] still produces the message.  Any other character class (alpha, alnum, blank) also produces the message.  Preceding the character class with some other character (except ^, of course) makes the message go away.

Is this a bug in regcomp() somehow?

Benno Schulenberg <bens>
Group administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attached Files
file #47360:  regcomp-errno-test.patch added by brand (741B - text/x-diff)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by brand (Updated the item)
  • -email is unavailable- added by bens (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-05-16 bens StatusNone Invalid
        Open/ClosedOpen Closed
    2019-08-18 brand Attached File- Added regcomp-errno-test.patch, #47360

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code