5 ms·

This is an area the newer languages get right - I don’t think Rust or Go has any undefined behavior? I wish they would have some kind of super strict mode for C

This is an area the newer languages get right - I don’t think Rust or Go has any undefined behavior? I wish they would have some kind of super strict mode for C or C++ where compilation fails unless you somehow fix things at the call sites to tell the compiler the behavior you want explicitly.

steveklabnik 2y ago
Safe Rust has no undefined behavior. Unsafe Rust does.
- vlovich123 2y ago
  cough std::env::set_var cough :D.
  - ultimaweapon 2y ago
    To be fair the UB caused by this function come from the underlying C implementation and this function already marked as unsafe on 2024 edition.
  - whytevuhuni 2y ago
    std::env::set_var [1] has already been changed to unsafe in the 2024 edition of the compiler [2]. So yeah, such things exist, but what's important is what the compiler devs choose to do once such issues are found. The C++ compiler devs say "That's an unfortunate case that cannot be fixed." The Rust devs say "That's a bug, here's the issue link." [1] https://doc.rust-lang.org/std/env/fn.set_var.html https://doc.rust-lang.org/std/env/fn.set_var.html [2] https://doc.rust-lang.org/edition-guide/rust-2024/newly-unsafe-functions.html https://doc.rust-lang.org/edition-guide/rust-2024/newly-unsa...
    - vlovich123 2y ago
      Yes I know all that. Just pointing out that “safe” Rust in practice can have unsoundness because of unsoundness in the underlying implementation. And yes it can be fixed but it did take quite a while to fix this one unfortunately (not that marking it unsafe meaningfully changes things)
      - steveklabnik 2y ago
        "software has bugs" isn't a particularly interesting thing. The point is, safe Rust has no UB. If mistakes are made, they're fixed.
        vlovich123 2y ago
        I’m not arguing that purely Safe Rust has UB theoretically and I’m 100% sympathetic to the difficulty. I’m saying in practice unsoundness can creep in from the real world and even the std library is not immune from this. This is even ignoring unsoundness due to compiler bugs which are smaller issues for now (but will become more so as ecosystems lag on updating the compiler). It doesn’t hurt anything to acknowledge that safe Rust can be unsafe due to mistakes in abstractions while simultaneously acknowledging that Rust still has orders of magnitudes fewer memory safety issues than c/c++ even with these problems. As for this specific bug, this kind of bug took a long time to fix for what it’s worth since it can take up to 3 years for a new edition to allow for fixing it. And “fixing” it doesn’t actually fix the unsoundness in existing code - it just changes the responsibility of who’s supposed to validate the usage is safe. It basically shifts the “blame” to the user for holding their tool wrong because code patterns that had been documented as being sound are now documented as being unsound and the user has to figure out how to make it safe once more. I’m not trying to cast blame or aspersions - mistakes happen and that this was dealt with shows the strength of Rust’s ability to solve these problems vs c++ which is hopeless. But pretending like safe Rust exists purely in a vacuum devoid of interaction with the real world isn’t helpful I think. I say all this with the utmost respect to your expertise and we basically agree on a lot of rust-related things. I just disagree slightly on the messaging here.
        steveklabnik 2y ago
        > we basically agree on a lot of rust-related things. I suspect we do too! > It doesn’t hurt anything to acknowledge that safe Rust can be unsafe due to mistakes in abstractions I think that the core disagreement here is not that I think that it's harmful, it just seems incredibly banal to me. That is, like, of course it can! So bringing it up feels like an attempt at a "gotcha" that's not really a gotcha.
jjmarr 2y ago
> I wish they would have some kind of super strict mode for C or C++ where compilation fails unless you somehow fix things at the call sites to tell the compiler the behavior you want explicitly. The C++ language committee _does not_ want to add more annotations to increase memory safety.
- tialaramex 2y ago
  Several programming languages can testify to the fact than a Benevolent Dictator For Life is not a panacea. Several more than testify that having a Committee to design the language is likewise not a panacea. Perhaps uniquely C++ can clarify for us that both is in fact worse than either alone.
  - pjmlp 2y ago
    Same applies to C.
    - tialaramex 2y ago
      Do you see Brian and Dennis dominating WG14 meetings? Nope. They moved on, Bjarne Stroustrup never did. After his initial prototypes and his first book about C++ he's written lots more books and papers, he's lectured classes, he's given huge numbers of talks, all of them about his baby, C++. If you ask WG21 people directly they'll insist he's just one vote (ah yes, JTC1 consensus "voting") but for example WG21 says it will heed the "advice" of its Direction Group, a self-selecting handful of people which is dedicated to following advice from a book written by Bjarne and weirdly always giving exactly the same advice as Bjarne, which makes sense because its most notable member is Bjarne but this advice is signed "The Direction Group" ... It's like being surprised that the UN Security Council keeps making decisions which favour Russia.
      - pjmlp 2y ago
        It doesn't change the fact C is equally a design by committee language with all the negativity it entails. In fact, WG14 very clearly has acted against Dennis when he submitted papers that could have improved C's safer. Maybe his fat pointers proposal was not good enough, but apparently is wasn't something worth improving upon either. C authors indeed moved on, first with Alef (which granted had a few design issues), Limbo and finally Go, as C as being driven by WG14 was no longer their thing, C on Plan 9 isn't even C89 compliant.
zyedidia 2y ago
I think data races can cause undefined behavior in Go, which can cause memory safety to break down. See https://research.swtch.com/gorace https://research.swtch.com/gorace for details.
almostgotcaught 2y ago
you realize UB is basically an escape hatch from the standard for compilers right? it's not like a flaw in the language, it's gaps negotiated by the standards committee (well for the most part i guess). so the reason new languages don't have UB is because new languages don't have multiple implementations (go definitely doesn't, does anyone use rust-gcc?).
- Dylan16807 2y ago
  You only need implementation-defined behavior to grease the wheels of multiple implementations. You don't need the gaping void of undefined for that use. There's a big difference between "it'll be some number, not promising which one" and "the program loses definition and anything can break, often even retroactively".
  - almostgotcaught 2y ago
    Potato potato. My point is UB isn't an accident it's intentional. Mind you I'm not saying it's great, just that it's not some kind of slipup.
    - maxlybbert 2y ago
      "Implementation defined" and "undefined" are different things. On my laptop, sizeof(long) is 8; that's implementation defined. It could be different on my phone, or my desktop, or my work laptop. Undefined means, roughly, "doing X is considered nonsensical, and the compiler does not have to do anything reasonable with code that does X." In "Design and Evolution of C++," Stroustrup says that undefined behavior applies to things that should be errors, but that for some reason the committee doesn't think the compiler will necessarily be able to catch. When he came up with new ideas for the language, he would often have to choose between making a convoluted rule that his compiler could reliably enforce, or a simple rule that his compiler couldn't always give a sensible error message for. For instance, the original compilers relied on the system's linker. If the compiler could interact with the linker, it could perhaps detect violations of the One Definition Rule ( https://en.cppreference.com/w/cpp/language/definition https://en.cppreference.com/w/cpp/language/definition ), but since the linker might have been written by a completely different company, and it's acceptable for different source files to be compiled by different compilers (and even be written in other languages -- https://en.cppreference.com/w/cpp/language/language_linkage https://en.cppreference.com/w/cpp/language/language_linkage ) and put together by the linker, and it's common for binary libraries to be sold without source, there's no guarantee that the compiler will ever have the information necessary to detect a violation of the One Definition Rule. So the committee says that violations create a nonsense program, which isn't required to behave in any particular way.
pjmlp 2y ago
Older languages as well, those that weren't a copy-paste from C with extras. Modula-2, Ada, Object Pascal, Eiffel, Delphi,...

steveklabnik 2y ago

Safe Rust has no undefined behavior. Unsafe Rust does.

vlovich123 2y ago
cough std::env::set_var cough :D.
- ultimaweapon 2y ago
  To be fair the UB caused by this function come from the underlying C implementation and this function already marked as unsafe on 2024 edition.
- whytevuhuni 2y ago
  std::env::set_var [1] has already been changed to unsafe in the 2024 edition of the compiler [2]. So yeah, such things exist, but what's important is what the compiler devs choose to do once such issues are found. The C++ compiler devs say "That's an unfortunate case that cannot be fixed." The Rust devs say "That's a bug, here's the issue link." [1] https://doc.rust-lang.org/std/env/fn.set_var.html https://doc.rust-lang.org/std/env/fn.set_var.html [2] https://doc.rust-lang.org/edition-guide/rust-2024/newly-unsafe-functions.html https://doc.rust-lang.org/edition-guide/rust-2024/newly-unsa...
  - vlovich123 2y ago
    Yes I know all that. Just pointing out that “safe” Rust in practice can have unsoundness because of unsoundness in the underlying implementation. And yes it can be fixed but it did take quite a while to fix this one unfortunately (not that marking it unsafe meaningfully changes things)
    - steveklabnik 2y ago
      "software has bugs" isn't a particularly interesting thing. The point is, safe Rust has no UB. If mistakes are made, they're fixed.
      - vlovich123 2y ago
        I’m not arguing that purely Safe Rust has UB theoretically and I’m 100% sympathetic to the difficulty. I’m saying in practice unsoundness can creep in from the real world and even the std library is not immune from this. This is even ignoring unsoundness due to compiler bugs which are smaller issues for now (but will become more so as ecosystems lag on updating the compiler). It doesn’t hurt anything to acknowledge that safe Rust can be unsafe due to mistakes in abstractions while simultaneously acknowledging that Rust still has orders of magnitudes fewer memory safety issues than c/c++ even with these problems. As for this specific bug, this kind of bug took a long time to fix for what it’s worth since it can take up to 3 years for a new edition to allow for fixing it. And “fixing” it doesn’t actually fix the unsoundness in existing code - it just changes the responsibility of who’s supposed to validate the usage is safe. It basically shifts the “blame” to the user for holding their tool wrong because code patterns that had been documented as being sound are now documented as being unsound and the user has to figure out how to make it safe once more. I’m not trying to cast blame or aspersions - mistakes happen and that this was dealt with shows the strength of Rust’s ability to solve these problems vs c++ which is hopeless. But pretending like safe Rust exists purely in a vacuum devoid of interaction with the real world isn’t helpful I think. I say all this with the utmost respect to your expertise and we basically agree on a lot of rust-related things. I just disagree slightly on the messaging here.
        steveklabnik 2y ago
        > we basically agree on a lot of rust-related things. I suspect we do too! > It doesn’t hurt anything to acknowledge that safe Rust can be unsafe due to mistakes in abstractions I think that the core disagreement here is not that I think that it's harmful, it just seems incredibly banal to me. That is, like, of course it can! So bringing it up feels like an attempt at a "gotcha" that's not really a gotcha.

jjmarr 2y ago

> I wish they would have some kind of super strict mode for C or C++ where compilation fails unless you somehow fix things at the call sites to tell the compiler the behavior you want explicitly. The C++ language committee _does not_ want to add more annotations to increase memory safety.

tialaramex 2y ago
Several programming languages can testify to the fact than a Benevolent Dictator For Life is not a panacea. Several more than testify that having a Committee to design the language is likewise not a panacea. Perhaps uniquely C++ can clarify for us that both is in fact worse than either alone.
- pjmlp 2y ago
  Same applies to C.
  - tialaramex 2y ago
    Do you see Brian and Dennis dominating WG14 meetings? Nope. They moved on, Bjarne Stroustrup never did. After his initial prototypes and his first book about C++ he's written lots more books and papers, he's lectured classes, he's given huge numbers of talks, all of them about his baby, C++. If you ask WG21 people directly they'll insist he's just one vote (ah yes, JTC1 consensus "voting") but for example WG21 says it will heed the "advice" of its Direction Group, a self-selecting handful of people which is dedicated to following advice from a book written by Bjarne and weirdly always giving exactly the same advice as Bjarne, which makes sense because its most notable member is Bjarne but this advice is signed "The Direction Group" ... It's like being surprised that the UN Security Council keeps making decisions which favour Russia.
    - pjmlp 2y ago
      It doesn't change the fact C is equally a design by committee language with all the negativity it entails. In fact, WG14 very clearly has acted against Dennis when he submitted papers that could have improved C's safer. Maybe his fat pointers proposal was not good enough, but apparently is wasn't something worth improving upon either. C authors indeed moved on, first with Alef (which granted had a few design issues), Limbo and finally Go, as C as being driven by WG14 was no longer their thing, C on Plan 9 isn't even C89 compliant.

zyedidia 2y ago

I think data races can cause undefined behavior in Go, which can cause memory safety to break down. See https://research.swtch.com/gorace https://research.swtch.com/gorace for details.

almostgotcaught 2y ago

you realize UB is basically an escape hatch from the standard for compilers right? it's not like a flaw in the language, it's gaps negotiated by the standards committee (well for the most part i guess). so the reason new languages don't have UB is because new languages don't have multiple implementations (go definitely doesn't, does anyone use rust-gcc?).

Dylan16807 2y ago
You only need implementation-defined behavior to grease the wheels of multiple implementations. You don't need the gaping void of undefined for that use. There's a big difference between "it'll be some number, not promising which one" and "the program loses definition and anything can break, often even retroactively".
- almostgotcaught 2y ago
  Potato potato. My point is UB isn't an accident it's intentional. Mind you I'm not saying it's great, just that it's not some kind of slipup.
  - maxlybbert 2y ago
    "Implementation defined" and "undefined" are different things. On my laptop, sizeof(long) is 8; that's implementation defined. It could be different on my phone, or my desktop, or my work laptop. Undefined means, roughly, "doing X is considered nonsensical, and the compiler does not have to do anything reasonable with code that does X." In "Design and Evolution of C++," Stroustrup says that undefined behavior applies to things that should be errors, but that for some reason the committee doesn't think the compiler will necessarily be able to catch. When he came up with new ideas for the language, he would often have to choose between making a convoluted rule that his compiler could reliably enforce, or a simple rule that his compiler couldn't always give a sensible error message for. For instance, the original compilers relied on the system's linker. If the compiler could interact with the linker, it could perhaps detect violations of the One Definition Rule ( https://en.cppreference.com/w/cpp/language/definition https://en.cppreference.com/w/cpp/language/definition ), but since the linker might have been written by a completely different company, and it's acceptable for different source files to be compiled by different compilers (and even be written in other languages -- https://en.cppreference.com/w/cpp/language/language_linkage https://en.cppreference.com/w/cpp/language/language_linkage ) and put together by the linker, and it's common for binary libraries to be sold without source, there's no guarantee that the compiler will ever have the information necessary to detect a violation of the One Definition Rule. So the committee says that violations create a nonsense program, which isn't required to behave in any particular way.

pjmlp 2y ago

Older languages as well, those that weren't a copy-paste from C with extras. Modula-2, Ada, Object Pascal, Eiffel, Delphi,...