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

61–70 of 116 posts

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

#61

Post by frollogaston »

samiv wrote: post #21
gspr wrote: post #15

Earlier quoted context omitted.

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-upo…

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 testi…

Trying wasm is still on my todo list, but this sounds like how I'd expect it to work

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

#63

Post by frollogaston »

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…

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.

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

#64

Post by frollogaston »

DonHopkins wrote: post #50
groundzeros2015 wrote: post #42

Earlier quoted context omitted.

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.

You sounds like the misattributed Bill Gates of 2026.

Even before RAM got very expensive recently, it had already plateaued. Like 32 GB was still considered a lot for a PC and was about the same price as a decade prior.

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

#65

Post by Joker_vD »

unwind wrote: post #3

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.

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.

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

#66

Post by pjmlp »

yjftsjthsd-h wrote: post #57
pjmlp wrote: post #17

Earlier quoted context omitted.

No worries, it is sandboxed. /s

Why /s? That does massively reduce the exposure

As much as an OS process, on a modern OS that is.

The bounds checking story is only on the external limits of linear memory segments.

If memory gets corrupted inside a linear memory segment, it can equally well be exploited to change execution behaviour, which for many scenarios is already good enough for the attacker.

Yet these kind of attack vectors usually are dropped from blog posts selling WebAssembly as a revolutionary bytecode.

It is only yet another one since various others that came and went since UNCOL became an idea.

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

#67

Post by DonHopkins »

jstimpfle wrote: post #37
unwind wrote: post #3

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.

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.

Nothing is sane in a language that lets you say 4["Foo!"]

Array indexing in C is just pointer arithmetic wearing Groucho Marx Glasses.

C combines the flexibility and power of assembly language with the user-friendliness of assembly language.

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

#68

Post by senfiaj »

koolala wrote: post #19
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.

Not sure about SIMD. If you mean WASM, the main advantage of WASM32 over WASM64 is execution speed if it runs on a 64-bit runtime. This is because pointer accesses are simply 64-bit base pointer + 32/33-bit offset (the 32-bit pointer value in WASM program + some 32-bit optional offset). Since the offset in the memory access is already trimmed to 32/33-bit (in a 32-bit half of the register) at machine instruction level there is no possibility to escape the 8GB virtual memory cage that Chrome allocates, thus no need for additional runtime checks. WASM64, on the other hand, can escape without such checks.

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

#69

Post by phickey »

muvlon wrote: post #35
gspr wrote: post #15

Earlier quoted context omitted.

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-upo…

> 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.

Wasip1 did not specify sockets. Some implementations have made non-standard additions to add them, but sockets were not added to the standard until wasip2.

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

#70

Post by jstimpfle »

DonHopkins wrote: post #67
jstimpfle wrote: post #37

Earlier quoted context omitted.

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.

Nothing is sane in a language that lets you say 4["Foo!"] Array indexing in C is just pointer arithmetic wearing Groucho Marx Glasses. C combines the flexibility and power of assembly language with the user-friendliness of assembly language.

> Nothing is sane in a language that lets you say 4["Foo!"]

I just had a look at your HN profile page and was struck by the irony of seeing your Forth vs Lisp vs Postscript code examples there. Now consider that I've never written code like 4["Foo!"], even though I know it's possible, but in other languages you constantly have to do mental gymnastics to get any real work done, and those are allegedly so much saner !???

Post reply on HN