3 ms·

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

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

tadfisher 5mo ago
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 https://github.com/oven-sh/bun/pull/30728
- nsagent 5mo ago
  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.
- jojomodding 5mo ago
  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.
  - mswphd 5mo ago
    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_pointer_provenance_and_will_it/ https://www.reddit.com/r/rust/comments/1hxjdvp/eli5_what_is_...
    - tialaramex 5mo ago
      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.
  - nicce 5mo ago
    Unsafe code still mostly needs lifetimes. It extends the functionality, not removing them. I wonder how much nasty things they have done then.
- K0nserv 5mo ago
  > 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.

tadfisher 5mo ago

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 https://github.com/oven-sh/bun/pull/30728

nsagent 5mo ago
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.
jojomodding 5mo ago
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.
- mswphd 5mo ago
  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_pointer_provenance_and_will_it/ https://www.reddit.com/r/rust/comments/1hxjdvp/eli5_what_is_...
  - tialaramex 5mo ago
    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.
- nicce 5mo ago
  Unsafe code still mostly needs lifetimes. It extends the functionality, not removing them. I wonder how much nasty things they have done then.
K0nserv 5mo ago
> 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.