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

ernesernesto.github.io116 pointsby birdculture108 comments

Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

Hacker News
You can get real breakpoints, memory watching, etc in browser with the chrome debugging extension
by fyrn_
I would recommend the VSCode WASM DWARF debugging extension instead of the Chrome extension nowadays:
https://marketplace.visualstudio.com/items?itemName=ms-vscod...
This allows to setup an IDE-like 'press F5 to build and start into a debug session' in VSCode, with the debuggee running in Chrome.
E.g. see:
https://floooh.github.io/2023/11/11/emscripten-ide.html
by flohofwoe
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
by rvz
No worries, it is sandboxed. /s
by pjmlp
which of these vulnerabilities are most concerning to you in wasm programs?
by koolala
Also https://00f.net/2018/11/25/webassembly-doesnt-make-unsafe-la...
by jedisct1
Is it better to render directly in WASM or could you do game logic in WASM and then render in JavaScript with a JS graphics engine?
by deadbabe
Fun game! The demo works great on mobile except for some small font sizes and you can't hover over items to see the tooltip before selecting them.
by hiccuphippo
The memory64 proposal was merged into upstream last year, any reason to opt into 32 bit despite that?
by xydone
I already posted the link in another reply, but this is a good overview why wasm32 is usually the better choice over wasm64:
https://spidermonkey.dev/blog/2025/01/15/is-memory64-actuall...
TL;DR: wasm64 has slower memory load/store operation because it requires 'software bounds checking', so unless you absolutely need more than 4 GB RAM, wasm32 is the better choice.
by flohofwoe
Apple
by whizzter
You don't need 4GB and it wastes memory to make pointers twice as big? Even Linux supports running 64-bit code in a 32-bit address space ("x32 ABI") for this reason.
by trumpdong
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.
by sestep
I did the same with one of small games I have developed. It wasn't that hard. I only needed to tweak the build script and to fix some minor issues, like changing how main function works and swapping color components in the result picture. I did use SDL2 for it, but without OpenGL, so, I had no problems with shaders or something similar.
by Panzerschrek
FTA: I was serializing asset structs directly to disk (pak file) that had raw pointers in them
I’m surprised that that works in WASM. Wouldn’t a tiny change in your memory usage (say if you toggle your “log startup progress” flag) load data at a different address?
by Someone
Usually you do "pointer-fixup" where you convert them to relative-offsets on write and then back to absolute-offsets on read.
by mwkaufma
Meta: a space is missing in the title.
Since this is one of the bugs, I always recommemd writing
```
    game->boardPieces = swAlloc(sizeof(ThingHandle*) * row * column);
```
Like this instead:
```
    game->boardPieces = swAlloc(sizeof *game->boardPieces * row * column);
```
It's not 100% better, but it cuts out a few tokens which helps readability and moves the significant asterix further left where I think it's easier to spot.
by unwind
Frankly, "sizeof(T*)" should generate a warning if T is anything other than void, or a function type.
Yes, I know that C technically allows rather heterogenous representations for pointers to different types, but in practice there is difference only between object pointers and function pointers.
by Joker_vD
> Meta: a space is missing in the title.
I like the word "everybug" :-D
by ErroneousBosh
Honestly, I think I'm more likely to get your form wrong than the original one. This doesn't obviously look wrong to me:
```
   game->boardPieces = swAlloc(sizeof game->boardPieces * row * column);
```
Maybe I find this harder to parse because I'm not used to sizeof without brackets (though I know it's valid). But I think the bigger deal is that your version has a bug if the star is missing whereas there's has a bug if the star is present; it's easier to spot something extra than it is to spot something missing.
by quietbritishjim
It's totally true, using sizeof like a function is one of my pet peeves. Even the kernel people do it but it's WRONG and you are right.
But ACSHUALLY, how you write allocation is like this
```
    #define sane_alloc(type, count) ((type *) malloc(sizeof (type) * (count)))

    game->boardPieces = sane_alloc(BoardPiece, row * column);
```
The kernel people seem to finally have figured out this one in 2026.
by jstimpfle
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.
by thewavelength
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.
by koolala
Because a web page shouldn’t use 4 GB of ram, and the win is that each pointer can be half the size (better for memory and cache).
The real mistake is requiring pointer to be 64 bit when most programs don’t use it.
by groundzeros2015
64 bit was added in WebAssembly 2.0 (finished in 2022 according to Wikipedia). I know what doesn't answer any it wasn't there in the first place.
by ape4
Because 64-bit WASM can be quite a bit slower than 32-bit WASM:
https://spidermonkey.dev/blog/2025/01/15/is-memory64-actuall...
TL;DR: wasm64 requires explicit heap bounds checks, while in wasm32 the memory mapping hardware does it for free.
E.g. quote:
"The only reason to use Memory64 is if you actually need more than 4GB of memory.
Memory64 won’t make your code faster or more “modern”. 64-bit pointers in WebAssembly simply allow you to address more memory, at the cost of slower loads and stores."
by flohofwoe
I believe 32-bit was chosen partially due to implementation efficiency reasons. It makes sense because you can allocate a 4GB mapping, so there is no need for a second software virtual memory layer. Also perhaps they internally require tagged pointers, which are much cheaper, especially if aligned, if the pointer is only 32 bits
by PhilipRoman
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.
by whizzter
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 the Web, really). Maybe this will bear fruit in that people will make more Native user interfaces again.
by arcadialeak
Wasm still doesn't let you make native user interfaces, the UI is in the web browser. You can put native UI components into a React Native or Electron app though.
by frollogaston