Maybe they want a quick switchover and the UB is replicating existing problems so it is net neutral for the codebase (but positive future coz developers can do future work on rust without synchronizing two codebase? ).
So this is a clear case where the LLM generated Rust port introduced a bug:
> The Zig original is a packed struct with the same shape; it "worked" only because Zig has no reference aliasing or provenance rules to violate. The Rust port inherited the shape without rethinking the API surface.
exactly. If they wanted to iterate on their port they would add lifetime annotations here, which are the tool Rust be uses to ensure safety. They're just kicking the unsafety block down the road. This accomplishes nothing and is not how you get Rust to deliver its safety promise.
Lifetimes would prevent the particular use-after-free example here, but the UB that miri currently flags would still exist, as it's related to pointer provenance, not lifetimes.
Yeah, This whole type relies on the C or C++ style "pointers as integers" hack, and while that perhaps works fine in Zig (I don't know) it's wrong or at least a bad idea in Rust. Rust wants you to prefer "integers as pointers" instead because it has different validity rules and lacks C++ "pointer zap".
In C or C++ you conventionally store a suitably large integer (uintptr_t for example) and then when you sometimes need a pointer you just cast that integer to a pointer. Under the proposed C provenance semantics PNVI-ae-udi this gets you exposed provenance.
In Rust you conventionally store a pointer, and then when you sometimes need an integer you ask for the address bits from the pointer (which on popular platforms will be the whole pointer but as an integer) or you make pointers from the integer you have with no claim to their provenance. If you're careful this gets you what Rust calls "strict" provenance, it's just straight PNVI.
OK fixed! As you clearly know this space well, what do think would make this project better? I was thinking I wanted to see a heatmap of memory access (pages?), and more detailed explaination of the opcodes, but getting the thing working took quite a while so I got a bit tired and stopped at the booting milestone, but I like the project a lot and now it is in a notebook I can basically probe any part of the system with dataviz tools to make it more tangible. Do you have anything you think would be helpful or cool for learners that you have not seen before in an emulator?
It counts every instruction and blends the colours for the three active modes. Then the height represents idleness. So it's a pretty high resolution measure!
We do something similar at work, called metadev. It sits above all repos and git submodules othe repos in, and works with multiple changes with multiple sessions with worktrees, and stores long term knowledge in /learnings. Our trick has been to put domain specific prompts in the submodules, and developer process in metadev. Because of the way Claude hierarchically includes context, the top repo is not polluted with too much domain specifics.
Two husbands without kids, working in tech, have a huge amount of cash, time capacity and ideation opportunity. I felt these added up to a huge advantage for getting quality shit done and taking risks. Fair play.
reply