tre regex in single regcomp.c file

tre regex in single regcomp.c file

[Julien Ramseier]

Hello,

Any reason most of the TRE regex sources have been merged in a single 3k lines 
file (regcomp.c)?
This makes diff-ing them against the original sources[0] very painful.

Would a patch to split them back be accepted?

[0] https://github.com/laurikari/tre/

- Julien

Re: tre regex in single regcomp.c file

[Szabolcs Nagy]

* Julien Ramseier <j.ramseier@gmail.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

Re: tre regex in single regcomp.c file

[Rich Felker]

On Thu, Jun 16, 2016 at 05:12:24PM +0200, Szabolcs Nagy wrote:
> * Julien Ramseier <j.ramseier@gmail.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[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.

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

Re: tre regex in single regcomp.c file

[Julien Ramseier]

> Le 16 juin 2016 à 17:25, Rich Felker <dalias@libc.org> a écrit :
>> 
>> 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.
> 

That makes sense.
Thank you both for the explanations.

- Julien