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

(ernesernesto.github.io)

69 points by birdculture2 days ago

13 comments

diath2 hours ago
With regards to 1), do not write/read structs directly to/from files. Instead write a proper serializer/deserializer. Without it, you may encounter another breakage soon when a different compiler/compiler options insert different struct padding bytes, which will then once again make your data non-portable, and a maliciously crafted save file with no length/size field validation on the deserializer level can lead to a variety of memory bugs.
- jstimpfle2 hours ago
 struct layout is well specified, it should be possible to avoid any padding issues by just aligning and by padding (with dummy members) correctly. The problem in practice is mostly integer representation (big-endian vs little-endian).
 - leni5362 hours ago
 Specified by whom? Not the C standard for sure. It is indeed soecified by individual ABIs, and ABIs don't tend to do anything too weird, but that's another question.
 - jstimpfle58 minutes ago
 looks like I was wrong, but here is the de-facto standard I was relying on over the years ;-). Not that I've memcpied many structs to file directly btw. <a href="http://www.catb.org/esr/structure-packing/" rel="nofollow">http://www.catb.org/esr/structure-packing/</a>
 - DanielHB1 hour ago
 If you modify or even just move fields around the struct that also changes the way they are serialized...You really need a serializer for this sort of thing because it can also include forwards compatibility of your data structures.
 - jstimpfle59 minutes ago
 sure, if you change the struct, it will now be different.
Someone16 minutes ago
FTA: I was serializing asset structs directly to disk (pak file) that had raw pointers in themI’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?
arcadialeak3 hours ago
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.
- pjmlp3 hours ago
 ActiveX, Alchemy, PNaCL,...
 - genxy2 hours ago
 JVM, Z-Machine, P-Code.
 - yjftsjthsd-h11 minutes ago
 I remember Java applets; when did z-machine and p-code make it to the browser?
 - DonHopkins8 minutes ago
 Everything made it to the browser through emulation.UCSD Pascal:<a href="https://archive.org/details/UCSD_Pascal_1.1_1" rel="nofollow">https://archive.org/details/UCSD_Pascal_1.1_1</a>Wizardry:<a href="https://archive.org/details/WizardryProvingGrounds" rel="nofollow">https://archive.org/details/WizardryProvingGrounds</a>
 - DonHopkins9 minutes ago
 Woz's own Sweet 16 Dream Machine on the Integer Basic ROMS of the Apple II! ;)<a href="https://en.wikipedia.org/wiki/SWEET16" rel="nofollow">https://en.wikipedia.org/wiki/SWEET16</a>
- gspr3 hours ago
 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.
 - muvlon2 hours ago
 > WASI still leaves something to be desired. Why can't I have raw sockets and file access and stuff, in a POSIX-like way?FWIW, that's exactly what they shipped first, with WASI preview 1 (wasip1). You can still use this today, and all runtimes with any level of WASI support will be able to run it.
 - postalrat2 hours ago
 If enough people adopt identical or similar js glue then they can use that for a new standard. If people dont care about a standard interface then why both creaing a new standard? Look what happened with jquery selectors and ajax. People loved it and it became the new standard built into browsers.
 - samiv3 hours ago
 You can call JS in which you can manipulate the DOM.Of course architecturally (also regarding your file access) it's better to use the wasm for logic as much as possible where the web (HTML/JS) provides the UI and IO, data flows into wasm for work and results flow back to the web.This also has the benefit that you can keep your original C/C++ source code much more platform agnostic which helps reusability and testing.
 - gspr3 hours ago
 > You can call JS in which you can manipulate the DOM.Well sure. But for me, the promise of WASM was to make the browser "just another platform". Now it's "this special platform where you have to access some of the most important functionality through FFI interop with a very high-level, very opinionated language".> Of course architecturally (also regarding your file access) it's better to use the wasm for logic as much as possible where the web (HTML/JS) provides the UI and IO, data flows into wasm for work and results flow back to the web.OK, but like, I wanted the browser to be "just another platform". I don't want to use JS, and I consider HTML orthogonal to my logic. I realize that's not where we're at, but that's what I dreamt of. Hence my disappointment. Which is OK, I don't matter :)> This also has the benefit that you can keep your original C/C++ source code much more platform agnostic which helps reusability and testing.It feels the opposite to me.
 - jayd1643 minutes ago
 Hmm well I guess I don't quite get what counts as "just another platform." Surely every platform is going to have the native APIs that you need to abstract over. Why is WASM different?Is it just a matter of WASM being too new to have full featured wrappers and APIs for your language of choice?
 - trumpdong2 hours ago
 [dead]
 - trumpdong2 hours ago
 There's no way to draw on a canvas in WASM either. You just decided to write JS wrapper functions for that. But you didn't write wrapper functions for DOM manipulation.
 - gspr2 hours ago
 You're right. But at least the JS wrapper for the canvas is just used for setting up the shared memory, if I remember correctly?At any rate: this doubly makes my point.
thewavelength3 hours ago
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.
- whizzter3 hours ago
 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.
 - thewavelength3 hours ago
 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?
 - whizzter1 hour ago
 1: Something like Figma could probably offload some of the memory pressure to GPU textures. (But they'd probably run into safety browser limits before that).2: Most runtimes are 64bit already, A runtime detecting a wasm32 binary will just continue to generate code with the current JIT compiler whilst WASM64 will require another JIT (and perhaps memory system since WASM32 runtimes are often based on "hacks" where 4gb of address space is reserved but not given real memory so that the JIT compiler gets an easier job without security implications).
 - koolala3 hours ago
 what would make it break? i think the program just calls a 64 bit wasm memory function if it uses the capability
- PhilipRoman2 hours ago
 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
 - Findecanor2 hours ago
 WASM has a (pointer + i32) address mode, and the effective address is 33 bits. So WASM implementations use 8GB mappings ...
- ape41 hour ago
 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.
- koolala3 hours ago
 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.
- groundzeros20151 hour ago
 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.
 - DonHopkins57 minutes ago
 You sounds like the misattributed Bill Gates of 2026.
unwind4 hours ago
Meta: a space is missing in the title.Since this is one of the bugs, I always recommemd writing<pre><code> game->boardPieces = swAlloc(sizeof(ThingHandle*) * row * column); </code></pre> Like this instead:<pre><code> game->boardPieces = swAlloc(sizeof *game->boardPieces * row * column); </code></pre> 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.
- jstimpfle2 hours ago
 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<pre><code> #define sane_alloc(type, count) ((type *) malloc(sizeof (type) * (count))) game->boardPieces = sane_alloc(BoardPiece, row * column); </code></pre> The kernel people seem to finally have figured out this one in 2026.
- quietbritishjim2 hours ago
 Honestly, I think I'm more likely to get your form wrong than the original one. This doesn't obviously look wrong to me:<pre><code> game->boardPieces = swAlloc(sizeof game->boardPieces * row * column); </code></pre> 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.
- ErroneousBosh3 hours ago
 > Meta: a space is missing in the title.I like the word "everybug" :-D
hiccuphippo2 hours ago
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.
xydone3 hours ago
The memory64 proposal was merged into upstream last year, any reason to opt into 32 bit despite that?
- sestep3 hours ago
 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.
 - senfiaj1 hour ago
 Sometimes I wonder whether it's possible to run the wasm code in a separate sandboxed process to eliminate a lot of checks. I mean optionally, because normally JS calls wasm code synchronously in the same address space. The bridge will add more latency when there is a transition between JS and wasm. It's obviously complicated because some data structures can also be shared, such as SharedArrayBuffer.
 - xydone3 hours ago
 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!
- trumpdong2 hours ago
 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.
 - Narishma1 hour ago
 > Even Linux supports running 64-bit code in a 32-bit address space ("x32 ABI") for this reason.I don't think that ever had much, if any, adoption and it looks like it will be removed in the next few releases.
- whizzter3 hours ago
 Apple
 - koolala3 hours ago
 they limit some good things on purpose just for the sake of ecosystem competition. but with this they are slowly implementing it?
nhinck33 hours ago
Probably a firefox bug but the interface hit boxes are misaligned when fullscreen
DonHopkins13 minutes ago
I've been porting Micropolis (SimCity Classic) to WASM / WebGPU / Svelte 5. Emscripten + Embind compile the C++ engine and glue it to TypeScript/Svelte/Runes/Reactivity; TypeScript owns UI, rendering, and callback handlers.I agree with the article's main lessons: wasm32 pointer size, don't serialize structs with pointers, debug native 32-bit when you can, WebGL/WebGPU is stricter than desktop GL, Emscripten export flags still bite. I hit some of the same categories; the parts that were actually tricky for Micropolis are below.Svelte 5 runes ($state, $derived, etc.) work in plain .ts modules, not just .svelte templates. That matters because the WASM bridge is a reactive module the HUD, command bus, and Vitest all import -- not a component-only trick. The file has to be MicropolisReactive.svelte.ts so runes compile under the same Vite/SvelteKit pipeline as the app; plain .ts breaks in Node with "$state is not defined".Embind API surface -- what to expose and what to leave out:<a href="https://github.com/SimHacker/MicropolisCore/blob/main/packages/micropolis-engine/src/emscripten.cpp" rel="nofollow">https://github.com/SimHacker/MicropolisCore/blob/main/packag...</a><pre><code> // This file uses emscripten's embind to bind C++ classes, // C structures, functions, enums, and contents into JavaScript, // so you can even subclass C++ classes in JavaScript, // for implementing plugins and user interfaces. // // Wrapping the entire Micropolis class from the Micropolis (open-source // version of SimCity) code into Emscripten for JavaScript access is a // large and complex task, mainly due to the size and complexity of the // class. The class encompasses almost every aspect of the simulation, // including map generation, simulation logic, user interface // interactions, and more. </code></pre> The comments in that file go on to describe the strategy for wrapping: Core Simulation Logic, Memory and Performance Considerations, Direct Memory Access, User Interface and Rendering, Callbacks and Interactivity, and Optimizations.The engine callback virtual interface bridged C++ to JS via JSCallback:<a href="https://github.com/SimHacker/MicropolisCore/blob/main/packages/micropolis-engine/src/js_callback.h" rel="nofollow">https://github.com/SimHacker/MicropolisCore/blob/main/packag...</a>In the old NeWS/Hyperlook, TCL/Tk/X11, SWIG/Python/PyGTK, and SWIG/Python/TurboGears/AMF/Flash versions, this callback interface used to be a stringly typed general purpose event callback interface, which I tightened up into a strict C++ interface and corresponding typescript interface, so embind could help me integrate it safely and cleanly with TypeScript and Svelte Runes.TypeScript handlers that update rune-backed state (sendMessage, didTool, budget hooks, etc.):<a href="https://github.com/SimHacker/MicropolisCore/blob/main/apps/micropolis/src/lib/MicropolisReactive.svelte.ts" rel="nofollow">https://github.com/SimHacker/MicropolisCore/blob/main/apps/m...</a>Simulator attach/detach, singleton engine load, wiring JSCallback into Micropolis:<a href="https://github.com/SimHacker/MicropolisCore/blob/main/apps/micropolis/src/lib/MicropolisSimulator.ts" rel="nofollow">https://github.com/SimHacker/MicropolisCore/blob/main/apps/m...</a>The pattern: C++ fires callbacks with enough context for the UI; TS updates $state; components read micropolisReactive (peek / poke / memory / getSnapshot) instead of calling Embind or touching HEAP* directly. That is where the rubber hits the road for interactivity.Heap access is its own footgun. Emscripten may expose Module.wasmMemory, HEAPU16, or neither until init; some getters throw if you read too early. Centralized helper:<a href="https://github.com/SimHacker/MicropolisCore/blob/main/apps/micropolis/src/lib/wasm/heap.ts" rel="nofollow">https://github.com/SimHacker/MicropolisCore/blob/main/apps/m...</a>Bridge design, Vitest against real WASM, teardown order with Embind lifetimes:<a href="https://github.com/SimHacker/MicropolisCore/blob/main/documentation/designs/wasm-bridge-and-testing-trajectory.md" rel="nofollow">https://github.com/SimHacker/MicropolisCore/blob/main/docume...</a>Map rendering: WebGPU tile renderer with canvas fallback (legacy WebGL frozen, now reimplementing in WebGPU). The renderer reads 16 bit flags + tile indices from direct simulator memory views into WASM linear memory (mapData / mopData), not per-frame Embind copies.<a href="https://github.com/SimHacker/MicropolisCore/blob/main/packages/tile-renderer/src/WebGPUTileRenderer.ts" rel="nofollow">https://github.com/SimHacker/MicropolisCore/blob/main/packag...</a><a href="https://github.com/SimHacker/MicropolisCore/blob/main/documentation/designs/unified-webgpu-renderer.md" rel="nofollow">https://github.com/SimHacker/MicropolisCore/blob/main/docume...</a>City saves are a defined binary format (.cty), not fwrite of engine structs. Live map data is views into WASM linear memory (mapData / mopData), not embedded native pointers -- same idea as the article's side-table fix, but that is how this codebase is already structured.Why I find this stack interesting: original SimCity engine lineage, narrow Embind surface on purpose, reactive TS facade so automation and UI share one sim without reviving the old Python/SWIG/pyGTK path. Sprites (trains, choppers, generic orange monsters wrecking chaos and havoc -- definitely not Godzilla [TM], but possibly Trump adjacent) simulate in C++; compositing them in the WebGPU path is still work in progress.The WebGPU renderer is being built as a general stack with pluggable layers, including Sims content rendering (characters, animations, terrain, objects, walls, floors, ui effects, etc).Character animation demo:<a href="https://vitamoo.space" rel="nofollow">https://vitamoo.space</a>VitaMoo code:<a href="https://github.com/SimHacker/MicropolisCore/tree/main/packages/vitamoo" rel="nofollow">https://github.com/SimHacker/MicropolisCore/tree/main/packag...</a>Unified WebGPU Renderer:<a href="https://github.com/SimHacker/MicropolisCore/blob/main/documentation/designs/unified-webgpu-renderer.md" rel="nofollow">https://github.com/SimHacker/MicropolisCore/blob/main/docume...</a>Render Core Package:<a href="https://github.com/SimHacker/MicropolisCore/blob/main/documentation/designs/render-core-package.md" rel="nofollow">https://github.com/SimHacker/MicropolisCore/blob/main/docume...</a>Renderer Plugin Roadmap:<a href="https://github.com/SimHacker/MicropolisCore/blob/main/documentation/designs/renderer-plugin-roadmap.md" rel="nofollow">https://github.com/SimHacker/MicropolisCore/blob/main/docume...</a>Live Micropolis tile renderer and simulator demo (no other ui yet, work in progress):<a href="https://micropolisweb.com" rel="nofollow">https://micropolisweb.com</a>Demo of the simulator, cellular automata, and tile engine to Jerry Martin's music:<a href="https://www.youtube.com/watch?v=319i7slXcbI" rel="nofollow">https://www.youtube.com/watch?v=319i7slXcbI</a>Repo:<a href="https://github.com/SimHacker/MicropolisCore" rel="nofollow">https://github.com/SimHacker/MicropolisCore</a>
rvz3 hours ago
If you are porting anything from C into WebAssembly, keep in mind that you still inherit C based vulnerabilities. [0] [1][0] <a href="https://soft.vub.ac.be/Publications/2022/vub-tr-soft-22-02.pdf" rel="nofollow">https://soft.vub.ac.be/Publications/2022/vub-tr-soft-22-02.p...</a>[1] <a href="https://www.usenix.org/system/files/sec20-lehmann.pdf" rel="nofollow">https://www.usenix.org/system/files/sec20-lehmann.pdf</a>
- koolala3 hours ago
 which of these vulnerabilities are most concerning to you in wasm programs?
- jedisct12 hours ago
 Also <a href="https://00f.net/2018/11/25/webassembly-doesnt-make-unsafe-languages-safe/" rel="nofollow">https://00f.net/2018/11/25/webassembly-doesnt-make-unsafe-la...</a>
- pjmlp3 hours ago
 No worries, it is sandboxed. /s
 - yjftsjthsd-h3 minutes ago
 Why /s? That does massively reduce the exposure
pioh4 hours ago
i want to hack 99 night in the forest
senfiaj1 hour ago
[dead]
haeseong3 hours ago
[flagged]