Just rewrote @musllibc's glob() this afternoon (commit coming soon) - long overdue, but a new bug report pushed it forward.
-
Show this thread
-
Issue was failure to expand /foo/bar/* when foo is -r+x, which turned out to be not just a bug but indicative of extreme missed optimization.
1 reply 0 retweets 0 likesShow this thread -
Previously, glob recursed at each path component level, consumed lots of stack, and opened each dir for reading (the big correctness problem).
1 reply 0 retweets 0 likesShow this thread -
Now, at each level of recursion, it consumes a maximal prefix of [escaped-]literal path components, and only opens the resulting dir for reading if there is a remaining non-literal pattern component, recursing into entries that match it.
2 replies 0 retweets 1 likeShow this thread -
Replying to @RichFelker
Given /foo/bar/x and /foo/baz/x where foo is -r+x, would a glob of /foo/{bar,baz}/x work?
1 reply 0 retweets 0 likes -
-
-
Replying to @stevecheckoway
Rich Felker Retweeted Rich Felker
Yes, glibc/gnulib glob has it. Interestingly, their fnmatch doesn't, which is nice because it's more horrible for fnmatch which isn't allowed to allocate.https://twitter.com/RichFelker/status/1050861482953633792 …
Rich Felker added,
Rich Felker @RichFelkerReplying to @RichFelker @stevecheckowayBTW one reason musl doesn't implement this GNU extension is that standard fnmatch/glob expressions admit constant-space linear-time matching but with the brace extension it's necessarily quadratic-time (assuming constant-space restriction).1 reply 0 retweets 0 likes
(But their fnmatch is horrible and does allocate anyway; it converts the whole pattern and haystack to wchar_t[] temp buffers...)
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.