Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 16 Jun 2016 11:25:27 -0400
From: Rich Felker <>
Subject: Re: tre regex in single regcomp.c file

On Thu, Jun 16, 2016 at 05:12:24PM +0200, Szabolcs Nagy wrote:
> * Julien Ramseier <> [2016-06-16 16:31:12 +0200]:
> > Any reason most of the TRE regex sources have been merged in a single 3k lines 
> > file (regcomp.c)?
> creating internal interfaces for implementing a single
> self-contained public function (regcomp) is bad design.
> (even if you split the code up, all the code will be
> linked together if the public api symbol is referenced
> otherwise none of the code will be used, so you just
> create linking overhead and headaches around the internal
> api between the source files which must obey posix
> namespace rules etc.)

Yes, the main motivation was to get rid of external namespace
pollution without renaming all the internal functions to be
__-prefixed, and also to allow inter-procedural analysis

> > This makes diff-ing them against the original sources[0] very painful.
> the original tre is not suitable for libc use, at least
> the namespace issues, alloca use, aborts, debug printfs
> should be fixed.
> there were various other conformance issues and features
> not relevant to the c runtime, the parser was rewritten e.g.
> so diffing would be painful anyway.
> > Would a patch to split them back be accepted?
> unlikely
> it's much more likely that the regex engine will be rewritten.

If the goal is to send improvements or fixes upstream (that would mean
picking maintenance of TRE back up yourself, I think) the right way
would be to read musl's git logs and follow the changes that way.


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.