10 years ago, a coworker had a really hard time root-causing a bug. I shoulder-debugged it by noticing the bit patterns: it was a miscompile of LLVM itself by GCC, where GCC was using an x87 fldl/fstpl move for a union { double; int64; }. The active member was actually the int64, and GCC chose FP moved based on what was the first member of the union... but the int64 happened to be the representation of SNaN, so the instructions transformed it quietly to a qNaN as part of moving. The "fix" was to change the order of the union's members in LLVM. The bug is still open, though it's had recent activity: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58416
Yes, I'm trying to figure out which are still relevant and whether they target a modern C++, or intend to. I've been asking for a few years and haven't gotten positive answers. The only one that been brought up is TI, I added info in the updated draft: https://isocpp.org/files/papers/D3477R1.html
I'd honestly just start with musl libc. The one Emscripten supports mostly just imports the same syscalls as Linux, with some ugliness to be able to do some DCE. If you clean that up your embedder will only need to implement those syscalls.
Your phrasing leads me to believe that you distrust how web standards organizations approve new features? If that's not the case then I invite you to join the W3C Community Group and help avoid insecure additions w3.org/community/webassembly/
1. WebAssembly has almost no APIs to the platforms whereas Flash had a bunch (i.e. it's "as safe as JavaScript, because it can only call JavaScript").
2. The code is all new, as opposed to what I hear is a hard-to-maintain older codebase which wasn't designed with security in mind.
3. It's very static in that memory accesses are pretty easy to bounds check for the compiler.
Implementation-wise there's plenty of interesting things that can be done to tighten security of WebAssembly.