If that was true, then I would expect followups to reduce UB and unsafe in general, or at least requiring a lifetime for caller-owned memory.
replyBut I think their true strategy is to have AI produce "fixes" like these which will end up infecting the entire codebase: https://github.com/oven-sh/bun/pull/30728
> If that was true, then I would expect followups to reduce UB and unsafe in general, or at least requiring a lifetime for caller-owned memory.
replyIt's been like a day since the merge, presumably such followups are coming.
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.
replyLifetimes 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.
replyhttps://www.reddit.com/r/rust/comments/1hxjdvp/eli5_what_is_...
Unsafe code still mostly needs lifetimes. It extends the functionality, not removing them. I wonder how much nasty things they have done then.
replySo this is a clear case where the LLM generated Rust port introduced a bug:
reply> 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.