jfbastien

Dang, will fix when I get home! Thanks Nick, and hi!

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

Typo, I fixed it in the new draft: https://isocpp.org/files/papers/D3477R1.html

I added a mention of TI's hardware in my latest draft: https://isocpp.org/files/papers/D3477R1.html

As mentioned by others, we've dropped trigraph and deprecated rand (and offer an alternative). I also have:

* p2809 Trivial infinite loops are not Undefined Behavior * p1152 Deprecating volatile * p0907 Signed Integers are Two's Complement * p2723 Zero-initialize objects of automatic storage duration * p2186 Removing Garbage Collection Support

So it is possible to change things!

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

Hi! Thanks for the interest on my proposal. I have an updated draft based on feedback I've received so far: https://isocpp.org/files/papers/D3477R1.html

Hi! I'm JF. I half-jokingly threatened to do IEEE float in 2018 https://youtu.be/JhUxIVf1qok?si=QxZN_fIU2Th8vhxv&t=3250

I wouldn't want to lose the Linux humor tho!

Having it in .rodata is much nice than having it in .text

No, I’m a blade runner character.

You sound like fun at parties :p I’m glad you liked the oration and technical content though!

This is the way ;)

I will do prompt injection in the next talk, just for you

Good thing this was covered in the talk

I’m glad you appreciated me saying exactly this in the talk

That is entirely incorrect for the WebAssembly CG and WG.

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.

Interpreters can go a long way, but JIT code generation is required for really fast dynamic language implementation. That's quite a bit off for WebAssembly: https://github.com/WebAssembly/design/blob/master/FutureFeat...

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/

A few ways that come to mind:

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.

> What's the reasonable thing to do when a grow-memory instruction returns -1?

A good assumption is that your WebAssembly binary already has an implementation of malloc which calls grow_memory. It should do something sane, and you shouldn't need to worry: it's similar to having mmap fail on other platforms. What do you do when mmap fail? I usually just give up and abort, but in rare cases I'll do other fancy things.

> Are there high-quality polyfills available for older browsers?

Work had started in 2015 for a solid polyfill, but now all major browser vendors have shipped WebAssembly so that work wasn't seen as necessary anymore.

> How is forward-compatibility expected to be handled? Right now there's only WebAssembly with the core feature-set. What happens as some vendors start to add support for varying features such as GC, SIMD, threads, etc.?

Not that satisfying an answer, but https://github.com/WebAssembly/design/blob/master/FeatureTes...

Same organizations, different people, and enough time to experiment with (read: suffer pains from) things like asm.js and PNaCl for those people to agree that something like WebAssembly was a good idea.

In theory, yes, but WebAssembly current has put little effort on standardizing packaging and ABIs. That work is in progress here: https://github.com/WebAssembly/tool-conventions but is still very early. You'd then need each of these platform exposing a standard set of imports to WebAssembly binaries because from the compiler's perspective WebAssembly looks like an OS with a virtual ISA, so these embedder imports are kind of like an OS' syscalls. That's a lot of work, isn't very advanced yet, but in theory is all possible and WebAssembly was explicitly designed to make it possible.

Hmm, that website mirrors github but got stale: https://github.com/WebAssembly/design/blob/master/FutureFeat...

It now links to here: https://github.com/WebAssembly/design/issues/1079

The person maintaining that mirror went back to grad school, I'll see who maintains it now. Apologies for the 404.

You should be able to write a very basic WebAssembly compiler in much less than half a megabyte. The WebAssembly format itself can be assumed to already be pre-optimized, and is expressed in terms of i32/i64/f32/f64 with an infinite register set and stack machine, with a very well structured control flow. You really don't need a smart compiler to lower this to semi-efficient code. The runtime in a non-JavaScript embedder then has to expose a series of syscalls, but that's not very big either.

This is pure nonsense. WebAssembly is no more obscure than asm.js or minified JavaScript. "Binary" versus Unicode-enabled minified and transformed "source" is the same thing.

You can get text out of WebAssembly as well as you can get text out of minified JS.

Further, users don't care about this. It's literally just developers. Open Source / Free Software is a super valid discussion to have, but I highly doubt any non-technical user cares.

Amusingly, pcwalton brought up this discussion recently: https://twitter.com/pcwalton/status/872151997473972224

Correct, shared memory and atomics are likely the first big post-MVP feature: https://github.com/WebAssembly/threads/blob/master/proposals...

Source map is totally optional! It provides zero help in understanding asm.js or minified JS. I see what you're saying about binaries being opaque blobs, but I just don't see how that's different from asm.js or minified JS.

Kinda sounds like you're trolling pcwalton TBH: https://twitter.com/pcwalton/status/872151997473972224

I approve ;-)

WebAssembly is as Turing-complete as JavaScript is, and has fewer APIs. The only API it has JS doesn't really is grow_memory, and even that can kinda be done with ArrayBuffer.

I'm not sure what you think makes it the harbinger of closed web. As the WebAssembly CG chair, I'd be interested in understanding that.

FWIW I trust that the numbers were good when the Google and Mozilla folks gathered them, but I had nothing to do with numbers!

In particular, I haven't looked into validation. JSC doesn't treat asm.js any differently than JavaScript, so the comparison would be different as well.