wasi-libc

Could this work with https://github.com/webassembly/wasi-libc ? It seems like OP put together their own musl-based libc which is awesome, but being able to compile against WASI would open up a lot of possibilities. This also reminds me of the recent thread on user-mode linux -- how easy it would be to compile to WASM was definitely on my mind.

I merged a few PRs to SIMD optimize Wasm WASI libc, but it all got stalled in str(c)spn (which is slightly more sophisticated than the rest). There wasn't much appetite for any of it on Emscripten. https://github.com/WebAssembly/wasi-libc/pulls?q=is%3Apr+opt...

Yeah, using LLVM for anything trying to avoid UB is crazy. I got involved in a discussion with a Rust guy when trying to get C with SIMD intrinsics into wasi-libc where something that the C standard explicitly state is “implementation defined” (and so, sane, as we're targeting a single implementation - LLVM) can't be trusted, because LLVM may turn it back into UB because “reasons.” At this point Go and Zig made the right choice to dump it. I don't know about Rust. https://github.com/WebAssembly/wasi-libc/pull/593

Still trying to upstream my Wasm SIMD libc optimizations. https://github.com/WebAssembly/wasi-libc/pull/586

It's been a little under a month since I submitted the initial bits of this: https://news.ycombinator.com/item?id=43730458 I was asked to upstream (which I tried to, it's the linked issue), and about additional functions. Since then, the issue hasn't gained a lot of traction, but I implemented a few far more interesting algorithms, both by Wojciech Muła: SIMDized check which bytes are in a set: http://0x80.pl/notesen/2018-10-18-simd-byte-lookup.html (for strspn and strcspn). SIMD-friendly algorithms for substring searching: http://0x80.pl/notesen/2016-11-28-simd-strfind.html (for strstr and memmem). These basically "complete" the set of string.h methods. I also made sure the header compiles with C++, added a bunch of tests, and made it easier to integrate in your stuff if even it doesn't get upstreamed. If you're interested in diving into

A PR is a significant investment from me. I'd have to figure out where something like this is supposed to fit, how the build infra works, etc. One of the nice things about Go is how much that's a solved issue out of the box, compared to almost everything else; certainly compared to C. Pinging them in an issue: https://github.com/WebAssembly/wasi-libc/issues/580

> The problem is that in WASM-land we're heading towards WASI and WAT components, which is similar to the .NET, COM & IDL ecosystems. While this is actually really cool in terms of component and interface discovery, the downside is that it means you have to re-invent the world to work with this flavor of runtime. At the application level, you're generally going to write to the standards + your embedding. Companies that write embeddings are encouraced/incentivized to write good abstractions that work with standards to reduce user friction. For example, for making HTTP requests and responding to HTTP requests, there is WASI HTTP: https://github.com/WebAssembly/wasi-http It's written in a way that is robust enough to handle most use cases without much loss of efficiency. There are a few inefficiencies in the WIT contracts (that will go away