[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201026232543.GR534@brightrain.aerifal.cx>
Date: Mon, 26 Oct 2020 19:25:44 -0400
From: Rich Felker <dalias@...c.org>
To: Mark Wielaard <mark@...mp.org>
Cc: Max Rees <maxcrees@...com>, musl@...ts.openwall.com,
elfutils-devel@...rceware.org,
Érico Rolim <erico.erc@...il.com>
Subject: Re: Re: [QUESTION] Which fnmatch() functionality does
elfutils depend on?
On Mon, Oct 26, 2020 at 11:32:23PM +0100, Mark Wielaard wrote:
> Hi Max,
>
> On Mon, 2020-10-26 at 13:54 -0400, Max Rees via Elfutils-devel wrote:
> > On Mon Oct 26 01:28 PM, Érico Nogueira wrote:
> > > On Mon Oct 26, 2020 at 3:10 PM -03, Mark Wielaard wrote:
> > > > On Mon, 2020-10-26 at 12:03 -0300, Érico Nogueira via Elfutils-
> > > > devel
> > > > wrote:
> > > > > Do elfutils program actually depend on the extra functionality
> > > > > enabled by
> > > > > FNM_EXTMATCH? Is changing the flag to have no effect a "bug"?
> > > >
> > > > Yes. The extended wildcard pattern is relied upon by both
> > > > eu-strip with
> > > >
> > > > --keep-section=SECTION Keep the named section. SECTION is an
> > > > extended wildcard pattern. May be given
> > > > more than once.
> > > >
> > > > and eu-elfcompress with
> > > >
> > > > -n, --name=SECTION SECTION name to (de)compress, SECTION is an
> > > > extended wildcard pattern (defaults to
> > > > '.?(z)debug*')
> > > >
> > > > In the eu-strip case it might be reasoned that instead of a
> > > > wildcard pattern the user might most of the time simply provide
> > > > a section name as is (especially since the option may be given
> > > > multiple times). But in the case of eu-elfcompress the
> > > > program relies on the default SECTION name being an extended
> > > > wildcard pattern. So not supporting FNM_EXTMATCH breaks the
> > > > default functionality of eu-elfcompress.
> > >
> > > Understood, thank you. I'm replying to the musl mailing list as well,
> > > then, to hopefully gather more opinions, since I don't know what the
> > > best way of solving this would be.
> >
> > When I was working on porting elfutils to Adélie (kind of on the
> > backburner right now) I noticed this problem as well. Rather than try to
> > add FNM_EXTMATCH support to musl, I worked around it in elfutils in this
> > manner.
> >
> > 1. I changed the default like so:
> >
> > - add_pattern (".?(z)debug*");
> > + add_pattern (".debug*");
> > + add_pattern (".zdebug*");
> >
> > 2. I updated the corresponding help text to mention this new default.
> >
> > The user could do something similar themselves with multiple "-n"
> > options.
>
> That is a workaround to get a working build if your libc currently
> doesn't provide a working fnmatch with FNM_EXTMATCH. But it would still
> break the interface of the tools that currently accept an extended
> wildcard pattern. So I think the best way forward is adding
> FNM_EXTMATCH support to those libcs that don't support it yet (and
> maybe get it standardized).
As I stated in my other reply, I'm opposed to that because it does not
admit implementation with the same (very desirable) big-O properties,
and the "extmatch" syntax is not widely known or widely used. There
are very, very few programs actually making use of this, and it would
be preferable to see it go away rather than proliferate.
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.
