Earlier quoted context omitted.
JVM, Z-Machine, P-Code.
Woz's own Sweet 16 Dream Machine on the Integer Basic ROMS of the Apple II! ;) https://en.wikipedia.org/wiki/SWEET16 https://techwithdave.davevw.com/2024/05/running-sweet-16-ste...
[deleted]
Ported my C game to WASM, here's every bug that I hit
101–110 of 116 posts
Re: Ported my C game to WASM, here's every bug that I hit
#102Earlier quoted context omitted.
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 revol…
How could any general execution environment guarantee memory like that? That doesn't seem like a realistic expectation. You can write safe Rust code if you want memory guarantees in WASM but would you really want it to block the ability to run unsafe Rust code too?
Easy, see other bytecodes with bounds checking opcodes, and where use of unsafe bytecodes taint the executable on the verifier, which then requires explicit execution permission.
Re: Ported my C game to WASM, here's every bug that I hit
#103Earlier quoted context omitted.
ActiveX, Alchemy, PNaCL,...
Saying ActiveX here shows a fundamental misunderstanding of what both WASM and ActiveX are. Is ActiveX platform independent? No. it's exclusive to windows. Is it sandboxed? Nope, digital signing and prayer, does it implement a virtual machine? Nope. Compromises out the wazoo? efficiency, data orientation, or predictable performance? You betcha. ActiveX is closer to a DOM sandbox escape exploit than a real piece of en…
What is a fundamental misunderstanding is selling WebAssembly as the first time bleeding Web and native code has been achieved.
All those "look Python on the browser!" were already done by ActiveState with Perl, Python and Tcl.
Re: Ported my C game to WASM, here's every bug that I hit
#104Earlier quoted context omitted.
How could any general execution environment guarantee memory like that? That doesn't seem like a realistic expectation. You can write safe Rust code if you want memory guarantees in WASM but would you really want it to block the ability to run unsafe Rust code too?
Easy, see other bytecodes with bounds checking opcodes, and where use of unsafe bytecodes taint the executable on the verifier, which then requires explicit execution permission.
Taint it how? What kind of permissions? Your fix is a pop up warning on unsafe code?
Re: Ported my C game to WASM, here's every bug that I hit
#105I 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.
Re: Ported my C game to WASM, here's every bug that I hit
#106Earlier quoted context omitted.
> Wasm still doesn't let you make native user interfaces That's currently only not possible because nobody wants to do the work to create something like wasi-gfx ( https://wasi-gfx.dev/ ), but for native UI frameworks instead of 3D APIs. The inconvenient truth is that even "native" cross-platform applications hardly ever go through the trouble to target the platform-native UI framework (and instead they go through no…
I meant, in-browser wasm can't do native things like creating a blank non-browser window on my Mac like a Swift app could, no matter what libraries it uses.
[deleted]
Re: Ported my C game to WASM, here's every bug that I hit
#107Earlier quoted context omitted.
Easy, see other bytecodes with bounds checking opcodes, and where use of unsafe bytecodes taint the executable on the verifier, which then requires explicit execution permission.
Taint it how? What kind of permissions? Your fix is a pop up warning on unsafe code?
See, this is where knowing the history of bytecode formats since UNCOL, would be relevant.
Burroungs (1961),
https://en.wikipedia.org/wiki/Burroughs_Large_Systems
"In fact, all unsafe constructs are rejected by the NEWP compiler unless a block is specifically marked to allow those instructions. Such marking of blocks provide a multi-level protection mechanism."
"NEWP programs that contain unsafe constructs are initially non-executable. The security administrator of a system is able to "bless" such programs and make them executable, but normal users are not able to do this. (Even "privileged users", who normally have essentially root privilege, may be unable to do this depending on the configuration chosen by the site.) While NEWP can be used to write general programs and has a number of features designed for large software projects, it does not support everything ALGOL does."
CLR (2001)
https://learn.microsoft.com/en-us/dotnet/framework/tools/pev...
"Normally, code that is not verifiably type safe cannot run, although you can set security policy to allow the execution of trusted but unverifiable code."
IBM i (nee AS/400)
https://medium.com/@dhemanthc/ibm-i-architecture-how-timi-an...
"SLIC enforces IBM i’s unique object-based model. Rather than managing raw memory locations or file descriptors, all resources (programs, files, queues, data areas, libraries) are managed as named objects with properties, ownership, and permissions. This object model permeates everything in IBM i, from file systems to program calls."
Aka capabilities, and what CHERI project is pushing for as means to fix C and C++ code at hardware level.
Re: Ported my C game to WASM, here's every bug that I hit
#108Meta: 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.
Nah I'm still against repeating the type name all over the place, and the cast adds nothing good imnsho.
Re: Ported my C game to WASM, here's every bug that I hit
#109Earlier 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.
Nah I'm still against repeating the type name all over the place, and the cast adds nothing good imnsho.
The cast is at least 50% of why this is useful! You'll now get compile errors in case you did anything wrong.
Re: Ported my C game to WASM, here's every bug that I hit
#110Earlier quoted context omitted.
Taint it how? What kind of permissions? Your fix is a pop up warning on unsafe code?
See, this is where knowing the history of bytecode formats since UNCOL, would be relevant. Burroungs (1961), https://en.wikipedia.org/wiki/Burroughs_Large_Systems "In fact, all unsafe constructs are rejected by the NEWP compiler unless a block is specifically marked to allow those instructions. Such marking of blocks provide a multi-level protection mechanism." "NEWP programs that contain unsafe constructs are initia…
Isn't that like rejecting non-safe Rust code? Unsafe code plays an important role in the hot-loops of our ever-slowing computers.