Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ported my C game to WASM, here's every bug that I hit

ernesernesto.github.io

Post reply on HN
Print view View original

11–20 of 116 posts

Re: Ported my C game to WASM, here's every bug that I hit

#11

Post by whizzter »

thewavelength wrote: post #5

Why is a relatively new technology like WASM being limited to 32-bit pointers? Why repeat the same mistake again? > Web is 32-bit. Your 64-bit structs will break. This was the root cause of most of my bugs. WASM is 32-bit address space, pointers are 4 bytes not 8.

1: Letting your code break on pointer size changes is a quite bad sign imho (it's a sign that many other things are probably done with aliasing,etc and has a high risk of breaking due to undefined behaviour once gcc/clang gets around to utilizing it for an optimization).

2: iirc WASM was initially designed to be shimmable via Asm.JS to force laggards(Apple, Google) to implement it, Asm.JS in turn relied on specific rules in JS to get reliable 32bit arithmetic (but impossible for 64bit).

Wasm64 is implemented and works in Chrome and Firefox.. Apple is lagging again with Safari.

Re: Ported my C game to WASM, here's every bug that I hit

#14

Post by xydone »

sestep wrote: post #8
xydone wrote: post #4

The memory64 proposal was merged into upstream last year, any reason to opt into 32 bit despite that?

It's slower. Wasm32 can just reserve 8 GiB (32-bit pointer + 32-bit offset) of the virtual address space from the OS for each memory, so checking for out-of-bounds memory accesses imposes no performance penalty. Wasm64 can't do that, so each memory access is a bit slower.

Oh that's interesting, never noticed it in my experience but I have never written anything in wasm where it would matter. Makes perfect sense now that I think about it though. Thanks!

Re: Ported my C game to WASM, here's every bug that I hit

#15

Post by gspr »

arcadialeak wrote: post #9

I love how WASM is the thing that finally blurred the line between Web and Native programming, formely two realms isolated from each other for a long time. This both develops better awareness of how the code is executed by the hardware, which JavaScript devs often lack, and also brings skilled folks from the Native platforms who seem to be not so against WASM as they were against JavaScript (and all other parts of th…

I wanted to love it. As someone who hasn't done any web stuff since I was a child, I thought it'd amazing for it to be "just another platform".

I'm a bit disappointed though:

* There's still no way to do DOM manipulation. So then it's tempting to just grab a canvas and draw everything yourself, which of course wreaks on things like accessibility. I'm no fan of the web, but at least it comes with a somewhat agreed-upon way to display graphical stuff – it's a bit of a shame if we're all gonna just treat it like a surface for pixels.

* WASI still leaves something to be desired. Why can't I have raw sockets and file access and stuff, in a POSIX-like way? I understand that sandboxing is important, so this can all be on a per-request-basis, but still. This "just another platform" is still too far from just that.

* The amount of JS glue needed to actually load WASM stuff in the browser is annoying. The idea of needing a bunch of magic "bundlers" is sad.

Re: Ported my C game to WASM, here's every bug that I hit

#16

Post by pjmlp »

arcadialeak wrote: post #9

I love how WASM is the thing that finally blurred the line between Web and Native programming, formely two realms isolated from each other for a long time. This both develops better awareness of how the code is executed by the hardware, which JavaScript devs often lack, and also brings skilled folks from the Native platforms who seem to be not so against WASM as they were against JavaScript (and all other parts of th…

ActiveX, Alchemy, PNaCL,...

Re: Ported my C game to WASM, here's every bug that I hit

#17

Post by pjmlp »

rvz wrote: post #13

If you are porting anything from C into WebAssembly, keep in mind that you still inherit C based vulnerabilities. [0] [1] [0] https://soft.vub.ac.be/Publications/2022/vub-tr-soft-22-02.p... [1] https://www.usenix.org/system/files/sec20-lehmann.pdf

No worries, it is sandboxed. /s

Re: Ported my C game to WASM, here's every bug that I hit

#18

Post by thewavelength »

whizzter wrote: post #11
thewavelength wrote: post #5

Why is a relatively new technology like WASM being limited to 32-bit pointers? Why repeat the same mistake again? > Web is 32-bit. Your 64-bit structs will break. This was the root cause of most of my bugs. WASM is 32-bit address space, pointers are 4 bytes not 8.

1: Letting your code break on pointer size changes is a quite bad sign imho (it's a sign that many other things are probably done with aliasing,etc and has a high risk of breaking due to undefined behaviour once gcc/clang gets around to utilizing it for an optimization). 2: iirc WASM was initially designed to be shimmable via Asm.JS to force laggards(Apple, Google) to implement it, Asm.JS in turn relied on specific r…

Thanks!

1: True, although it also limits the addressable memory and the typical 4GB limit seems less these days. I’m thinking of large apps like Figma running in the browser.

2: Will existing 32-bit WASM binaries break on WASM64 engines or does the binary have a flag for compatibility?

Re: Ported my C game to WASM, here's every bug that I hit

#19

Post by koolala »

thewavelength wrote: post #5

Why is a relatively new technology like WASM being limited to 32-bit pointers? Why repeat the same mistake again? > Web is 32-bit. Your 64-bit structs will break. This was the root cause of most of my bugs. WASM is 32-bit address space, pointers are 4 bytes not 8.

32 is better for a lot of things like simd. the strength of it is wasm can do both types now and js can't unfortunately. a number in js is strictly 64.

Re: Ported my C game to WASM, here's every bug that I hit

#20

Post by koolala »

thewavelength wrote: post #18
whizzter wrote: post #11

Earlier quoted context omitted.

1: Letting your code break on pointer size changes is a quite bad sign imho (it's a sign that many other things are probably done with aliasing,etc and has a high risk of breaking due to undefined behaviour once gcc/clang gets around to utilizing it for an optimization). 2: iirc WASM was initially designed to be shimmable via Asm.JS to force laggards(Apple, Google) to implement it, Asm.JS in turn relied on specific r…

Thanks! 1: True, although it also limits the addressable memory and the typical 4GB limit seems less these days. I’m thinking of large apps like Figma running in the browser. 2: Will existing 32-bit WASM binaries break on WASM64 engines or does the binary have a flag for compatibility?

what would make it break? i think the program just calls a 64 bit wasm memory function if it uses the capability
Post reply on HN