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 28220 invoked from network); 26 Oct 2020 23:25:59 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 26 Oct 2020 23:25:59 -0000 Received: (qmail 11681 invoked by uid 550); 26 Oct 2020 23:25:57 -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 11657 invoked from network); 26 Oct 2020 23:25:56 -0000 Date: Mon, 26 Oct 2020 19:25:44 -0400 From: Rich Felker To: Mark Wielaard Cc: Max Rees , musl@lists.openwall.com, elfutils-devel@sourceware.org, =?utf-8?B?w4lyaWNv?= Rolim Message-ID: <20201026232543.GR534@brightrain.aerifal.cx> References: <723b967389be88475206c5afc280c3be02ab677c.camel@klomp.org> <20201026175430.GA6473@sachiel> <73a9e67dd5887f31663ef3ac4e9c683a133b3a0d.camel@klomp.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <73a9e67dd5887f31663ef3ac4e9c683a133b3a0d.camel@klomp.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] 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