From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 27916 invoked from network); 26 Oct 2020 23:23:52 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 26 Oct 2020 23:23:52 -0000 Received: (qmail 7372 invoked by uid 550); 26 Oct 2020 23:23:47 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 28615 invoked from network); 26 Oct 2020 22:32:35 -0000 Message-ID: <73a9e67dd5887f31663ef3ac4e9c683a133b3a0d.camel@klomp.org> From: Mark Wielaard To: Max Rees , musl@lists.openwall.com Cc: elfutils-devel@sourceware.org, =?ISO-8859-1?Q?=C9rico?= Rolim Date: Mon, 26 Oct 2020 23:32:23 +0100 In-Reply-To: <20201026175430.GA6473@sachiel> References: <723b967389be88475206c5afc280c3be02ab677c.camel@klomp.org> <20201026175430.GA6473@sachiel> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Evolution 3.28.5 (3.28.5-10.el7) Mime-Version: 1.0 Subject: Re: [musl] Re: [QUESTION] Which fnmatch() functionality does elfutils depend on? Hi Max, On Mon, 2020-10-26 at 13:54 -0400, Max Rees via Elfutils-devel wrote: > On Mon Oct 26 01:28 PM, =C3=89rico Nogueira wrote: > > On Mon Oct 26, 2020 at 3:10 PM -03, Mark Wielaard wrote: > > > On Mon, 2020-10-26 at 12:03 -0300, =C3=89rico 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"? > > >=20 > > > Yes. The extended wildcard pattern is relied upon by both > > > eu-strip with > > >=20 > > > --keep-section=3DSECTION Keep the named section. SECTION is an > > > extended wildcard pattern. May be given > > > more than once. > > >=20 > > > and eu-elfcompress with > > >=20 > > > -n, --name=3DSECTION SECTION name to (de)compress, SECTION is an > > > extended wildcard pattern (defaults to > > > '.?(z)debug*') > > >=20 > > > 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. > >=20 > > 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. >=20 > When I was working on porting elfutils to Ad=C3=A9lie (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. >=20 > 1. I changed the default like so: >=20 > - add_pattern (".?(z)debug*"); > + add_pattern (".debug*"); > + add_pattern (".zdebug*"); >=20 > 2. I updated the corresponding help text to mention this new default. >=20 > 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). Cheers, Mark