gabriela_c
Joined 9 months ago
Joined 9 months ago
Well, it's true when it's written badly (eg. the same way as when somebody writes in-line "shellcode" by doing `*(T*)ptr = (T)val;` or similar.
I think there's some history of some compilers that were basically non-trivial to port to other architectures/bit-sizes b.c. of this piggybacking.
Why are we not showing the bad choices? On my computer I have hundreds of diffs stored by my agent code review tool that point to style/architecture failures (and in the end, the result of that iteration on the AI output)
I'm not quite sure how people are generating unsalvageable outputs. I'd never ship the result of a first AI pass, either. I review all the code and the architecture, within reason (eg: in Rust I don't preoccupy myself anymore with precisely scoping pub, or whatever, unless I'm making a library crate). I sent a "changes requested" prompt+json to my agent, and it interactively fixes everything (even style, even comments with manual patches with my in-review-tool editor)
- ~4.75x runtime speed increase (significantly slower than box64, faster than QEMU), 7x executed instruction count increase, 50x binary size increase
- emulates x86 abi until it calls out to external
- has to emulate a large part of x86 cpu state like EFLAGS, compute complex movs individually, etc
- only supports single-thread binaries
- no exception handling/unwinding
- doesnt support the full ISA
It's seriously the thing that worries (and bothers) me the most. I almost never let unedited LLM comments pass. At a minimum.
Most of the time, I use my own vibe-coded tool to run multiple GitHub-PR-review-style reviews, and send them off to the agent to make the code look and work fine.
It also struggles with doing things the idiomatic way for huge codebases, or sometimes it's just plain wrong about why something works, even if it gets it right.
And I say this despite the fact that I don't really write much code by hand anymore, only the important ones (if even!) or the interesting ones.
Also, don't even get me started on AI-generated READMEs... I use Claude to refine my Markdown or automatically handle dark/light-mode, but I try to write everything myself, because I can't stand what it generates.
I am in the same predicament as both of you, having grown up with unfiltered internet access, and not wanting it to have went any other way (I love my life, actually!)
There is a condescending tendency when people hear what I said above, to tell me that I am an outlier, or, God forbid, a "genius", and other equally worrying conclusions regarding my character.
I agree that, today, there are millions more ways that children can fall for objectively negative things, that have been completely, and intentfully engineered to be terrible in a way which can be exploited for profit.
But also, I simply think that, with enough access to mind-numbing content, for long enough... people will simply realize that, actually, they don't want that. At least, not just that.
Adults are not a good term for comparision in the matter of less aggressive addictions, like with social media, because they already have lives they want to escape, with responsibilities and whatnot.
These are not scientifically sourced claims, but, in my experience, children have a lot more time, energy, curiosity, and will/intent to create, for one reason or another, and they have been doing those things since time immemorial.
This is just a consequence of having access to ~the entirety of all human knowledge at their fingertips, with no restrictions, and with an incredible amount of free time at their disposal.
It's definitely convoluted as it comes to memory obtained from the stack, but for heap allocations, a debugger could trace the returns of the allocator APIs, use that as a beginning point of some data's lifetime, and then trace any access to that address, and then gather the high-level info on the address of the reader/writer.
Global variables should also be trivial (fairly so) as you'll just need to track memory accesses to their address.
(Of course, further work is required to actually apply this.)
For variables on the stack, or registers, though, you'll possibly need heuristics which account for reusage of memory/variables, and maybe maintain a strong association with the thread this is happening in (for both the thread's allocated stack and the thread context), etc.