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

31–40 of 116 posts

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

#31

Post by postalrat »

gspr wrote: post #15
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-upo…

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.

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

#32

Post by trumpdong »

xydone wrote: post #4

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

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.

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

#33

Post by Findecanor »

PhilipRoman wrote: post #26
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.

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

WASM has a (pointer + i32) address mode, and the effective address is 33 bits. So WASM implementations use 8GB mappings ...

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

#34

Post by jstimpfle »

diath wrote: post #29

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…

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

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

#35

Post by muvlon »

gspr wrote: post #15
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-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.

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

#36

Post by gspr »

trumpdong wrote: post #28
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…

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.

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.

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

#37

Post by jstimpfle »

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.

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

#38

Post by leni536 »

jstimpfle wrote: post #34
diath wrote: post #29

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…

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

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.

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

#40

Post by jedisct1 »

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

Also https://00f.net/2018/11/25/webassembly-doesnt-make-unsafe-la...
Post reply on HN