Date: Thu, 16 Jun 2016 11:25:27 -0400 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: Re: tre regex in single regcomp.c file On Thu, Jun 16, 2016 at 05:12:24PM +0200, Szabolcs Nagy wrote: > * Julien Ramseier <j.ramseier@...il.com> [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 optimizations. > > This makes diff-ing them against the original sources 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. > http://git.musl-libc.org/cgit/musl/commit/?id=ec1aed0a144b3e00e16eeb142c9d13362d6048e7 > > 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. Rich
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.