[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201027222515.GW534@brightrain.aerifal.cx>
Date: Tue, 27 Oct 2020 18:25:15 -0400
From: Rich Felker <dalias@...c.org>
To: Mark Wielaard <mark@...mp.org>
Cc: Florian Weimer <fweimer@...hat.com>, musl@...ts.openwall.com,
Érico Rolim <erico.erc@...il.com>,
elfutils-devel@...rceware.org, Max Rees <maxcrees@...com>
Subject: Re: 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
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.
