What’s the deal with #if _LIBC and other non-Emacs code?

What’s the deal with #if _LIBC and other non-Emacs code?

[Michal Nazarewicz]

Dear Emacs developers!

I’ve noticed quite some code in regex.c and regex.h which isn’t used by
Emacs or any executable distributed with Emacs.  Most notably, there are
blocks of code guarded with ‘#ifdef _LIBC’ macro and support for
alternative syntax which is never actually used.

To me this all looks like it could be safely removed simplifying and
shortening the code.

I would be happy to prepare patches doing just that, but first I’d like
to make sure that there’s nothing I’m missing.

-- 
Best regards
ミハウ “𝓶𝓲𝓷𝓪86” ナザレヴイツ
«If at first you don’t succeed, give up skydiving»

Re: What’s the deal with #if _LIBC and other non-Emacs code?

[Eli Zaretskii]

> From: Michal Nazarewicz <mina86@mina86.com>
> Date: Tue, 26 Jul 2016 00:58:06 +0200
> 
> I’ve noticed quite some code in regex.c and regex.h which isn’t used by
> Emacs or any executable distributed with Emacs.  Most notably, there are
> blocks of code guarded with ‘#ifdef _LIBC’ macro and support for
> alternative syntax which is never actually used.
> 
> To me this all looks like it could be safely removed simplifying and
> shortening the code.
> 
> I would be happy to prepare patches doing just that, but first I’d like
> to make sure that there’s nothing I’m missing.

This code is maintained by glibc, where those parts are used.
Although our version diverged quite a lot from the one in glibc, we
still have plans to merge them at some point.  So I think we shouldn't
remove those parts.

Thanks.

Re: What’s the deal with #if _LIBC and other non-Emacs code?

[Stefan Monnier]

> This code is maintained by glibc, where those parts are used.
> Although our version diverged quite a lot from the one in glibc, we
> still have plans to merge them at some point.  So I think we shouldn't
> remove those parts.

AFAIK, this code used to be in some version of glibc, but glibc has
moved to a completely different regexp implementation many years ago.
IIRC gnulib was the last non-Emacs package which shared this code, and
AFAIK gnulib also dropped this (not sure if it replaced it with
something else or what, tho).

So, my understanding is that this code is now 100% ours with no hope to
sync it with anyone else.


        Stefan

Re: What’s the deal with #if _LIBC and other non-Emacs code?

[Paul Eggert]

On 07/26/2016 04:42 AM, Stefan Monnier wrote:
> AFAIK, this code used to be in some version of glibc, but glibc has
> moved to a completely different regexp implementation many years ago.
> IIRC gnulib was the last non-Emacs package which shared this code, and
> AFAIK gnulib also dropped this (not sure if it replaced it with
> something else or what, tho).

Gnulib regularly merges as many glibc changes as it can, and is now 
using essentially the same implementation that glibc does. It should be 
fairly easy to merge the gnulib changes back into glibc, if someone 
wants to volunteer to do that.

> So, my understanding is that this code is now 100% ours with no hope to
> sync it with anyone else.

The Emacs regex code could also be merged into glibc, though that would 
be a somewhat bigger project than merging gnulib into glibc, as there 
has been little or no attempt to keep the Emacs copy in sync with glibc.

Re: What’s the deal with #if _LIBC and other non-Emacs code?

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Mon, 25 Jul 2016 22:42:55 -0400
> 
> > This code is maintained by glibc, where those parts are used.
> > Although our version diverged quite a lot from the one in glibc, we
> > still have plans to merge them at some point.  So I think we shouldn't
> > remove those parts.
> 
> AFAIK, this code used to be in some version of glibc, but glibc has
> moved to a completely different regexp implementation many years ago.

Sorry, I meant gnulib.

> IIRC gnulib was the last non-Emacs package which shared this code, and
> AFAIK gnulib also dropped this (not sure if it replaced it with
> something else or what, tho).
> 
> So, my understanding is that this code is now 100% ours with no hope to
> sync it with anyone else.

I wasn't aware we made such a decision.  AFAIR, last time this was
discussed the desire to merge with gnulib was still there, although
not the resources.

Re: What’s the deal with #if _LIBC and other non-Emacs code?

[Stefan Monnier]

> I wasn't aware we made such a decision.

That's not a decision we took.  The change was on gnulib's side
(apparently they switched to glibc's regexp implementation, which makes
a lot of sense, actually).


        Stefan

Re: What’s the deal with #if _LIBC and other non-Emacs code?

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Tue, 26 Jul 2016 11:33:47 -0400
> 
> > I wasn't aware we made such a decision.
> 
> That's not a decision we took.  The change was on gnulib's side
> (apparently they switched to glibc's regexp implementation, which makes
> a lot of sense, actually).

I meant the decision to abandon hope of merging.

Re: What’s the deal with #if _LIBC and other non-Emacs code?

[Stefan Monnier]

>> > I wasn't aware we made such a decision.
>> That's not a decision we took.  The change was on gnulib's side
>> (apparently they switched to glibc's regexp implementation, which makes
>> a lot of sense, actually).
> I meant the decision to abandon hope of merging.

AFAIK the code used in gnulib and glibc is very completely different
from Emacs's, so "merging" back into their code is not really
applicable.  We could try and take their code, add to it the features we
need, and then submit those changes back to them, tho.


        Stefan


PS: I'm not sure exactly what would be missing, but I expect that \s and
\c together with the ability to match on a pair of char* would be the
first candidates.

PPS: I think the most serious problem with our regexp code is its
occasional exponential worst case.  I think changing to another
implementation would make a lot of sense, but only if that other
implementation can use a "Thompson's NFA" style implementation to avoid
those pathological cases.