• qqq@lemmy.world
    link
    fedilink
    arrow-up
    5
    arrow-down
    1
    ·
    edit-2
    2 days ago

    I suppose we need to make definitions clearer.

    The definition of “a memory safe programming language” is not in debate at all in the programming community. I have no idea why you’re trying to change it.

    I’d argue those weren’t the best developers then

    This is incredibly arrogant, and, tbh, ignorant.

    You missed the point of the examples: those aren’t necessarily “easy mistakes” to make and of course a UAF is easy to spot in a 4 line program, the point is that there is no language construct in place to protect from these trivial memory safety issues. With respect to the “obviousness” of the std::string mistake, if you instead consider an opaque interface that requires a const char* as an input, you have no idea if it is going to try to reference of that pointer or not past the lifetime of the std::string. If you can’t see past the simplicity of an example to the bigger picture that’s not on me.

    • Zacryon@feddit.org
      link
      fedilink
      arrow-up
      2
      ·
      2 hours ago

      The definition of “a memory safe programming language” is not in debate at all in the programming community.

      Yes, my mistake. I’m sorry.

      This is incredibly arrogant, and, tbh, ignorant.

      You’ve willingly ignored the remaining part of that context, where I explicitly admitted problems in common usage. It was not my intention to come across as arrogant.

      there is no language construct in place to protect from these trivial memory safety issues

      Depending on what you mean by “language constructs”: there are, e.g. RAII or smart pointers. But they aren’t enforced. So it’s correct to say that C++ is inherently memory unsafe due to the lack of such enforcements. The discussions here changed my opinion about that.