Hacker News Reader

Comment by tlarkworthy | Hacker News Reader

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

View on HN

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.

But 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

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.

https://www.reddit.com/r/rust/comments/1hxjdvp/eli5_what_is_...

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.

Unsafe code still mostly needs lifetimes. It extends the functionality, not removing them. I wonder how much nasty things they have done then.

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

It's been like a day since the merge, presumably such followups are coming.

Reply on news.ycombinator.com