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 31441 invoked from network); 27 Oct 2020 22:25:32 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 27 Oct 2020 22:25:32 -0000 Received: (qmail 5930 invoked by uid 550); 27 Oct 2020 22:25:27 -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 5900 invoked from network); 27 Oct 2020 22:25:27 -0000 Date: Tue, 27 Oct 2020 18:25:15 -0400 From: Rich Felker To: Mark Wielaard Cc: Florian Weimer , musl@lists.openwall.com, =?utf-8?B?w4lyaWNv?= Rolim , elfutils-devel@sourceware.org, Max Rees Message-ID: <20201027222515.GW534@brightrain.aerifal.cx> References: <723b967389be88475206c5afc280c3be02ab677c.camel@klomp.org> <20201026175430.GA6473@sachiel> <73a9e67dd5887f31663ef3ac4e9c683a133b3a0d.camel@klomp.org> <20201026232543.GR534@brightrain.aerifal.cx> <87wnzc81r9.fsf@oldenburg2.str.redhat.com> <69fc8640a4ec2d22fdf3e6526c5f0040e42b524a.camel@klomp.org> <20201027170817.GS534@brightrain.aerifal.cx> <20201027221911.GB2691@wildebeest.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201027221911.GB2691@wildebeest.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Re: [QUESTION] Which fnmatch() functionality does elfutils depend on? On Tue, Oct 27, 2020 at 11:19:11PM +0100, Mark Wielaard wrote: > Hi Rich, > > On Tue, Oct 27, 2020 at 01:08:17PM -0400, Rich Felker wrote: > > On Tue, Oct 27, 2020 at 04:04:44PM +0100, Mark Wielaard wrote: > > > Right, it is also adopted by zsh and some other shells. The big-O > > > properties don't really matter in this case because fnmatch is used on > > > small input strings like file names (or in this case section names). > > > > They do because they're also in space, unless you want > > exponential-time which is huge even on small inputs, and greater than > > O(1) space requirement means the interface can't satisfy its contract > > to return a conclusive result for valid inputs. > > But that isn't the contract if fnmatch. fnmatch returns 0 for a match > and non-zero for either a non-match or some error. So if your > algorithm hits some error case, like out of memory, returning a > non-zero result is fine. > > I believe the extended wildcard pattern are widely supported and > useful. If you don't want to implement them because they aren't in any > standardized enough yet we can ask the Austin Group to add them to > fnmatch. They have adopted other GNU flags for fnmatch in the past. And I can ask them not to. Your hostility is really unwelcome here. Rich