Dan Gohman

Could you comment on the practical impact of this change? Which features in the wasi-libc build are you looking to disable? Or is there some other purpose here?

> i'm not sure if extended-const is ubiquitous among non-web runtimes though. It is in some, it's behind a flag in others, and it's expected to be easy to implement...

@kylo5aby I've now opened https://github.com/WebAssembly/tool-conventions/pull/254 which contains a wast test file exercising all of the Lime1 features.

@kateinoigakukun @sbc100 The build here is [failing](https://github.com/WebAssembly/wasi-sdk/actions/runs/11300097968/job/31432329465?pr=495) being unable to find "config.h" when build fts.c. Would you mind taking a look?

> The `read_link` function will return an error if the link's destination is an absolute path. There are three problems with this: > > * It _won't_ return an error...

@cgwalters Ah, thanks. I forget we added that. So yes, adding a `cap_std::fs::Dir::read_link_contents` function that calls that makes sense. And yeah, thinking about it more, I don't think this needs...

@cgwalters Yes, I'm open to supporting this, though I don't have much bandwidth for writing code for it at the moment. I tend to prefer a `RootDir`-like API like https://github.com/coreos/cap-std-ext/pull/54/...

I believe this is already done, in #356. `Dir` has a `read_link_contents` function [here](https://docs.rs/cap-std/latest/cap_std/fs/struct.Dir.html#method.read_link_contents).

As commented previously, I believe this is fixed. Please re-open or file new issues if there's anything else needed here!

As discussed [here](https://github.com/bytecodealliance/cap-std?tab=readme-ov-file#what-can-i-use-cap-std-for), cap-std is currently promoted for untrusted-input situations and not untrusted-code situations. I myself don't have a comprehensive list of what would be needed to handle untrusted code,...