libregex

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Next revision		 Previous revision
libregex [2017/04/20 04:27] – KyleEvanslibregex [2022/08/15 06:31] (current) – Fix BSDgrep link KubilayKocak
Line 1: Line 1:
-====== libregex ======+===== libregex ===== 
 ===== Problem ===== ===== Problem =====
-libgnuregex will be going away, and it would be great if [[BSDgrep|bsdgrep]] can again grow the capacity to handle GNU extensions. As far as I've found, the GNU extensions add:+ 
 +libgnuregex will be going away, and it would be great if [[KyleEvans/BSDgrep|bsdgrep]] can again grow the capacity to handle GNU extensions. As far as I've found, the GNU extensions add: 
   * Empty subexpressions/branches/patterns create a 0-length match at the beginning of the subject   * Empty subexpressions/branches/patterns create a 0-length match at the beginning of the subject
   * Missing quantifiers to BREs: \?, \+   * Missing quantifiers to BREs: \?, \+
Line 14: Line 17:
     * \`: start of subject string     * \`: start of subject string
     * \': end of subject string     * \': end of subject string
 +
 ===== Motivation ===== ===== Motivation =====
-As previously mentioned, libgnuregex and [[BSDgrep|bsdgrep]] could use GNU extensions. ''%%regex(3)%%'' in libc currently does not have the capability to handle these, and some have pitched in that they'd rather not add these extensions directly to libc, in the interest if keeping it purely POSIX conformant and speed.+ 
 +As previously mentioned, libgnuregex and [[KyleEvans/BSDgrep|bsdgrep]] could use GNU extensions. ''%%regex(3)%%'' in libc currently does not have the capability to handle these, and some have pitched in that they'd rather not add these extensions directly to libc, in the interest if keeping it purely POSIX conformant and speed.
  
 ===== Implementation Details ===== ===== Implementation Details =====
 +
 As of right now, I have floated two patches around freebsd-hackers@. Patch [1] is what implementing the GNU extensions on top of the current Spencer implementation would look like. It still has some bugs/kinks that need to be worked out, but it does generally work for less torturous use cases. This also includes a REG_POSIX flag so that one may turn off all extensions by default. As of right now, I have floated two patches around freebsd-hackers@. Patch [1] is what implementing the GNU extensions on top of the current Spencer implementation would look like. It still has some bugs/kinks that need to be worked out, but it does generally work for less torturous use cases. This also includes a REG_POSIX flag so that one may turn off all extensions by default.
  
Line 31: Line 37:
  
 [2] [[https://files.kyle-evans.net/freebsd/libregex.diff|libregex.diff]] [2] [[https://files.kyle-evans.net/freebsd/libregex.diff|libregex.diff]]
 +
 ===== Preparation / Intermediate Steps ===== ===== Preparation / Intermediate Steps =====
 +
 There are basically two intermediate steps that need to be taken: There are basically two intermediate steps that need to be taken:
 +
   - A patch needs to be introduced to put an end to the different instances of escaping an ordinary character and expecting an ordinary character. This is undefined behavior by POSIX standards, so we should start throwing errors for it. This is mostly so that we can use \b,B,w,W,s,S safely without having unintended side-effects because an application/port was expected it to be taken literally.   - A patch needs to be introduced to put an end to the different instances of escaping an ordinary character and expecting an ordinary character. This is undefined behavior by POSIX standards, so we should start throwing errors for it. This is mostly so that we can use \b,B,w,W,s,S safely without having unintended side-effects because an application/port was expected it to be taken literally.
 +
   - The above [2] patch, libregex.diff, needs to be applied, and the test suite from libc/tests should somehow be reused here so that we can automatically test both libregex and libc.   - The above [2] patch, libregex.diff, needs to be applied, and the test suite from libc/tests should somehow be reused here so that we can automatically test both libregex and libc.
  
 ===== Discussion ===== ===== Discussion =====
 +
 To represent points from previous discussions: To represent points from previous discussions:
  
 **Backreferences will enforce that EREs, like BREs, may sometimes require exponential time to match.** **Backreferences will enforce that EREs, like BREs, may sometimes require exponential time to match.**
 This is true. It would first require people/projects to start using backreferences in EREs, but ultimately, we could likely use some all-around improvements here. This is true. It would first require people/projects to start using backreferences in EREs, but ultimately, we could likely use some all-around improvements here.
 +
 +===== Feedback? =====
 +
 +Please do give feedback on this idea, as it has had relatively little. If by e-mail, please do make sure to CC the listed email address for KyleEvans.
 +
 +----
 +
 +{{tag>Stale}}
  
  • libregex.1492662430.txt.gz
  • Last modified: 2017/04/20 04:27
  • by KyleEvans