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

21–30 of 116 posts

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

#21

Post by samiv »

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…

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.

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

#22

Post by koolala »

whizzter wrote: post #12
xydone wrote: post #4

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

Apple

they limit some good things on purpose just for the sake of ecosystem competition. but with this they are slowly implementing it?

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

#23

Post by koolala »

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

which of these vulnerabilities are most concerning to you in wasm programs?

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

#24

Post by gspr »

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…

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

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

#25

Post by quietbritishjim »

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.

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.

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

#26

Post by PhilipRoman »

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

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

#27

Post by genxy »

pjmlp wrote: post #16
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,...

JVM, Z-Machine, P-Code.

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

#28

Post by trumpdong »

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…

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.

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

#29

Post by diath »

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.

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

#30

Post by trumpdong »

gspr wrote: post #24
samiv wrote: post #21

Earlier quoted context omitted.

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…

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

JS in the web context is what C or assembly is in the native context: something you have to use, because it's the foundation the platform is built on, and every language needs a way to interact with it, and good languages support it inline when you need it.
Post reply on HN