[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160616151224.GR22574@port70.net>
Date: Thu, 16 Jun 2016 17:12:24 +0200
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Subject: Re: tre regex in single regcomp.c file
* 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.)
> 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.
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.
> [0] https://github.com/laurikari/tre/
>
> - Julien
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.
