* [musl] glob(GLOB_BRACE) @ 2024-02-01 13:48 Andrew Cagney 2024-02-01 14:27 ` Rich Felker 0 siblings, 1 reply; 3+ messages in thread From: Andrew Cagney @ 2024-02-01 13:48 UTC (permalink / raw) To: musl FYI, It's on the BSDs and glibc. Found by libreswan's test framework on alpine. ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [musl] glob(GLOB_BRACE) 2024-02-01 13:48 [musl] glob(GLOB_BRACE) Andrew Cagney @ 2024-02-01 14:27 ` Rich Felker 2024-02-01 15:53 ` Andrew Cagney 0 siblings, 1 reply; 3+ messages in thread From: Rich Felker @ 2024-02-01 14:27 UTC (permalink / raw) To: Andrew Cagney; +Cc: musl 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 ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [musl] glob(GLOB_BRACE) 2024-02-01 14:27 ` Rich Felker @ 2024-02-01 15:53 ` Andrew Cagney 0 siblings, 0 replies; 3+ messages in thread From: Andrew Cagney @ 2024-02-01 15:53 UTC (permalink / raw) To: Rich Felker; +Cc: musl On Thu, 1 Feb 2024 at 09:27, Rich Felker <dalias@libc.org> wrote: > > 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. > 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. for libreswan, after some digging: 2007 new code added with glob(GLOB_BRACE) call 2014 #ifdef GLOB_BRACE added; it turns out due to musl 2024 while merging some glob() calls; problem re-discovered So libreswan took the path of least resistance. I suspect it wasn't alone. Including it would let libreswan's config files be consistent across platforms - no need for special documentation. However, I also wonder if libreswan needs GLOB_BRACE. It isn't needed to expand the recommended <<include /etc/ipsec.d/*.conf>>. I'll take that up with libreswan. ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2024-02-01 16:20 UTC | newest] Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2024-02-01 13:48 [musl] glob(GLOB_BRACE) Andrew Cagney 2024-02-01 14:27 ` Rich Felker 2024-02-01 15:53 ` Andrew Cagney
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/musl/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).