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 31365 invoked from network); 27 Oct 2020 22:25:05 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 27 Oct 2020 22:25:05 -0000 Received: (qmail 3977 invoked by uid 550); 27 Oct 2020 22:25:02 -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 30652 invoked from network); 27 Oct 2020 22:20:13 -0000 Date: Tue, 27 Oct 2020 23:19:11 +0100 From: Mark Wielaard To: Rich Felker Cc: Florian Weimer , musl@lists.openwall.com, =?iso-8859-1?Q?=C9rico?= Rolim , elfutils-devel@sourceware.org, Max Rees Message-ID: <20201027221911.GB2691@wildebeest.org> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201027170817.GS534@brightrain.aerifal.cx> User-Agent: Mutt/1.10.1 (2018-07-13) Subject: Re: [musl] Re: [QUESTION] Which fnmatch() functionality does elfutils depend on? 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. Cheers, Mark