[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240201142719.GV4163@brightrain.aerifal.cx>
Date: Thu, 1 Feb 2024 09:27:20 -0500
From: Rich Felker <dalias@...c.org>
To: Andrew Cagney <andrew.cagney@...il.com>
Cc: musl@...ts.openwall.com
Subject: Re: glob(GLOB_BRACE)
On Thu, Feb 01, 2024 at 08:48:01AM -0500, Andrew Cagney wrote:
> FYI, It's on the BSDs and glibc.
> Found by libreswan's test framework on alpine.
By the usual criteria, this one probably leans towards a no, at least
contingent on how constraining it is to support it.
If it happened at the fnmatch layer, it would very much be a no,
because that effectively imposes regex-equivalent (or at least very
close) matching algorithm complexity and is thereby impossible to do
efficiently in constant-space, vs the standard fnmatch language where
that is possible (and we do it).
For glob and GLOB_BRACE, it looks like it's "just" a matter of
iterating over the different expansions and applying glob to each, but
it seems to be underspecified how it interacts with escaping, special
chars, slashes, etc.
Do you have good reasons in favor of inclusion? My impression is that
everything that wants/needs it is shipping its own version of GNU glob
or whatever that has it, or else very little is using it; otherwise it
would have come up before. But if adding it allowed a lot of things to
drop GNU glob and just use the libc glob, that might be compelling.
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.
