-
Notifications
You must be signed in to change notification settings - Fork 200
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Initial FTS support #522
Initial FTS support #522
Conversation
a5caf7b
to
f9a396b
Compare
Add FTS implementation derived from musl-fts with a few modifications. The compiled fts.o is included in the libc.a archive, and the fts.h header is installed in the sysroot (`include/fts.h`). * fts/musl-fts: Add a copy of the musl-fts sources with modifications. * fts/patches: A set of patches to apply to the musl-fts sources. * fts/update-musl-fts.sh: A script to update the musl-fts sources with the patches applied. * fts/config.h: A configuration header included by the musl-fts sources. * test/smoke: Add a test suite for wasi-libc specific features that libc-test does not cover.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for working on this.
I assume if/when the upstream patch lands we can replace most of this with a git submodule? (i.e. remove the update script and the patch system?).
I wonder if its worth waiting a few days to see if upstream will simply accept the patch?
Given that the latest release was 8 years ago and the main maintainer has no public activity last 3 years, it will take a long time to land the patch in the upstream. |
Fair point :) |
|
||
+#if !HAVE_FCHDIR | ||
+ /* If we don't have fchdir, pretend that FTS_NOCHDIR is always set. */ | ||
+ options |= FTS_NOCHDIR; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
doesn't this introduce the behavior changes visible to fts-using application?
i guess it's safer to make fts_open fail unless FTS_NOCHDIR is given.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, setting NOCHDIR by default indeed introduces changes in how cwd changes while traversing.
However, changing cwd is an internal optimization in fts, and the expected cwd during traversing is not defined in manual pages of most of fts impls. So I don't think most of user applications can depend on cwd while traversing if FTS_NOCHDIR is not specified.
Thus applications without FTS_NOCHDIR
specified should work even if not changing cwd and we don't need to ban fts_open
calls without FTS_NOCHDIR
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I haven't reviewed the FTS code itself, but overall this looks good to me. If anyone has concerns about the BSD-3-clause license, please let us know, here or in a new issue.
@sunfishcode @sbc100 Can we merge this into the main branch as we haven't had any license concerns for the past 3 weeks? |
Merged! |
WebAssembly#522 did not include the necessary changes to the Makefile for libc_so build.
#522 did not include the necessary changes to the Makefile for libc_so build. Additionally, updated CI to check `libc_so` build too to avoid future breakage.
Close #520
Add FTS implementation derived from musl-fts with a few modifications. The compiled fts.o is included in the libc.a archive, and the fts.h header is installed in the sysroot (
include/fts.h
).