I don’t think that casting a range of bits as some other arbitrary type “is a bug nobody sees coming”.

C++ compilers also warn you that this is likely an issue and will fail to compile if configured to do so. But it will let you do it if you really want to.

That’s why I love C++

  • Kairos@lemmy.today
    829·
    3日前

    People just think that applying arbitrary rules somehow makes software magically more secure, like with rust, as if the compiler won’t just “let you” do the exact same fucking thing if you type the unsafe keyword

    • BatmanAoD@programming.dev
      23·
      3日前

      It’s neither arbitrary nor magic; it’s math. And unsafe doesn’t disable the type system, it just lets you dereference raw pointers.

      • Kairos@lemmy.today
        71·
        3日前

        That’s not what I meant. I understand that rust forces things to be more secure. It’s not not like there’s some guarantee that rust is automatically safe, and C++ is automatically unsafe.

          • vivendi@programming.devEnglish
            12·
            3日前

            No there is not. Borrow checking and RAII existed in C++ too and there is no formal axiomatic proof of their safety in a general sense. Only to a very clearly defined degree.

            In fact, someone found memory bugs in Rust, again, because it is NOT soundly memory safe.

            Dart is soundly Null-safe. Meaning it can never mathematically compile null unsafe code unless you explicitly say you’re OK with it. Kotlin is simply Null safe, meaning it can run into bullshit null conditions.

            The same thing with Rust: don’t let it lull you into a sense of security that doesn’t exist.

            • BatmanAoD@programming.dev
              21·
              3日前

              Borrow checking…existed in C++ too

              Wat? That’s absolutely not true; even today lifetime-tracking in C++ tools is still basically a research topic.

              …someone found memory bugs in Rust, again, because it is NOT soundly memory safe.

              It’s not clear what you’re talking about here. In general, there are two ways that a language promising soundness can be unsound: a bug in the compiler, or a problem in the language definition itself permitting unsound code. (unsafe changes the prerequisites for unsoundness, placing more burden on the user to ensure that certain invariants are upheld; if the code upholds these invariants, but there’s still unsoundness, then that falls into the “bug in Rust” category, but unsoundness of incorrect unsafe code is not a bug in Rust.)

              Rust has had both types of bugs. Compiler bugs can be (and are) fixed without breaking (correct) user code. Bugs in the language definition are, fortunately, fixable at edition boundaries (or in rare cases by making a small breaking change, as when the behavior of extern "C" changed).

              • vivendi@programming.devEnglish
                11·
                3日前

                Have you heard about cve-rs?

                https://github.com/Speykious/cve-rs

                Blazingly fast memory failures with no unsafe blocks in pure Rust.

                Edit: also I wish whoever designed the syntax for rust to burn in hell for eternity

                Edit 2: Before the Cult of Rust™ sends their assassins to take out my family, I am not hating on Rust (except the syntax) and I’m not a C absolutist, I am just telling you to be aware of the limitations of your tools

                  • vivendi@programming.devEnglish
                    12·
                    3日前

                    Yeah and those are the ones currently identified (btw that issue isn’t completely fixed) because rust never was nor advertised itself as sound. Meaning, you gotta be careful when writing Rust code too. Not as much as C++, but it’s not a magical shield against memory problems like people have been shilling it as.

                  • vivendi@programming.devEnglish
                    11·
                    3日前

                    A) Rust doesn’t have a formal specification other than “whatever the fuck our team hallucinated in this compiler version”

                    B) Doesn’t matter the definition if it fucks your day because you’re not careful.

                    Sure sure Heil Rust but be mindful of the fuck you’re doing before you get bit ¯\_ (ツ) _/¯

    • Speiser0@feddit.org
      11·
      3日前

      You don’t even need unsafe, you can just take user input and execute it in a shell and rust will let you do it. Totally insecure!

      • Ignotum@lemmy.world
        121·
        3日前

        Rust isn’t memory safe because you can invoke another program that isn’t memory safe?

        • Speiser0@feddit.org
          8·
          3日前

          My comment is sarcastic, obviously. The argument Kairos gave is similar to this. You can still introduce vulnerabilities. The issue is normally that you introduce them accidentally. Rust gives you safety, but does not put your code into a sandbox. It looked to me like they weren’t aware of this difference.

    • panda_abyss@lemmy.ca
      21·
      3日前

      I don’t know rust, but for example in Swift the type system can make things way more difficult.

      Before they added macros if you wanted to write ORM code on a SQL database it was brutal, and if you need to go into raw buffers it’s generally easier to just write C/objc code and a bridging header. The type system can make it harder to reason about performance too because you lose some visibility in what actually gets compiled.

      The Swift type system has improved, but I’ve spent a lot of time fighting with it. I just try to avoid generics and type erasure now.

      I’ve had similar experiences with Java and Scala.

      That’s what I mean about it being nice to drop out of setting up some type hierarchy and interfaces and just working with a raw buffers or function pointers.