From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/10143 Path: news.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: tre regex in single regcomp.c file Date: Thu, 16 Jun 2016 17:12:24 +0200 Message-ID: <20160616151224.GR22574@port70.net> References: Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1466089964 4624 80.91.229.3 (16 Jun 2016 15:12:44 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 16 Jun 2016 15:12:44 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-10156-gllmg-musl=m.gmane.org@lists.openwall.com Thu Jun 16 17:12:39 2016 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1bDYyF-0003Jq-1q for gllmg-musl@m.gmane.org; Thu, 16 Jun 2016 17:12:39 +0200 Original-Received: (qmail 9297 invoked by uid 550); 16 Jun 2016 15:12:36 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 9279 invoked from network); 16 Jun 2016 15:12:36 -0000 Mail-Followup-To: musl@lists.openwall.com Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Xref: news.gmane.org gmane.linux.lib.musl.general:10143 Archived-At: * 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.) > 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