5 ms·

The modern insistence on (absolute) memory safety feels like another symptom of regression. It is like going back to insisting you can and should be absolutely

The modern insistence on (absolute) memory safety feels like another symptom of regression. It is like going back to insisting you can and should be absolutely safe from HIV by making certain lifestyle choices. In the '80s we knew that the answer was being safer, not being safe. I am all for making C and C++ safer by adding mitigations for the most common security relevant bugs. Either on language level, or on tooling level or on OS level or on CPU level. Or a combination of them. But since making a language absolutely memory safe doesn't make it automatically impossible to have bugs at all (even security relevant bugs), we should consider everything a trade-off.

dwnvotee 3y ago
Yup, keep the zero-days comin
hurril 3y ago
This is a silly argument. Making a language _memory safe_ protects against one class of bugs and that has merit in and of itself. The fact that there are more classes does not negate the value of that. To borrow(lol!) your own analogy here: it makes $language Safer. Not safe.
_dain_ 3y ago
>It is like going back to insisting you can and should be absolutely safe from HIV by making certain lifestyle choices. In the '80s we knew that the answer was being safer, not being safe. This is a singularly bad analogy. HIV used to be a death sentence, but now we have effective treatments and prophylactics. What's the PrEP equivalent for buffer overflows? There isn't one.
- stkdump 3y ago
  Oh, there are lots of PrEP equivalents. For example NX. Or virtual memory more in general. Or static analysis. Etc etc. If you think the modern ecosystem is as memory bug prone as it was in the 80s, you are being incredibly naive.
hurril 3y ago
I'm new to properly native languages, but having worked with Rust for 6 months, I've yet to encounter a single crash that wasn't on part of my error handling. I _love_ C and I've written one C program every year for the last decade or two. I generally write something really stupid, but there's going to be crashes that "prints the stack pants." As in: I'll fudge up returning the stack from a function, basically. This proves nothing, of course. But Rust won't even let me fudge things up that way. This means that I have more time to spend fixing those other classes of bugs and that is the win!
- stkdump 3y ago
  I have been full time in C++ development for >15 years. I can count the number of times I had memory correctness issues that weren't discovered and fixed trivially on one hand, all of them very early in my career. As your adage, of course mine doesn't prove anything.
  - lpapez 3y ago
    I don't want to sound like I'm downplaying your carreer, but what kinds of projects did you work on for 15 years to have an experience this positive? For instance I find it incredible that you never had to debug and workaround a third party vendor DLL that you didn't have source for but that was leaking memory like crazy. This is the just one example of something that can be "fixed trivially" as you don't have source to modify, and is extremely common in some fields (i.e. embedded)
    - stkdump 3y ago
      I have been working on a monorepo C++ codebase with on the order of 1000 person years of development on it. And no, we didn't have major issues with memory leaks either. About on par with what I have seen in garbage collected languages. RAII works quite good most of the time.
      - lpapez 3y ago
        I take it that your project being a monorepo means you have access to the code and can change it when deemed neccessary? I get how that would be characterized as "trivially fixable", but I assure you that this is not the kind of projects people complain about when they discuss memory safety issues. Consider that some people need to send emails to vendor companies begging them to stop segfaulting, writing the stack or leaking memory. You're lucky if it gets fixed in a few months, because that means you wouldn't have to seek alternatives which would be even more time consuming. In conclusion, there are many people out there dealing with memory safety issues which are anything but "trivially fixable".
pjmlp 3y ago
It isn't modern, UNIX folks decided to ignore what was being done outside Bell Labs. Had UNIX not been free beer, history would have been quite different for C and C++.
imtringued 3y ago
Your analogy would work if every person having sex gets HIV. Buffer overflows are deeply rooted into C to the point that in the past some standard functions made buffer overflows mandatory.

dwnvotee 3y ago

Yup, keep the zero-days comin

hurril 3y ago

This is a silly argument. Making a language _memory safe_ protects against one class of bugs and that has merit in and of itself. The fact that there are more classes does not negate the value of that. To borrow(lol!) your own analogy here: it makes $language Safer. Not safe.

_dain_ 3y ago

>It is like going back to insisting you can and should be absolutely safe from HIV by making certain lifestyle choices. In the '80s we knew that the answer was being safer, not being safe. This is a singularly bad analogy. HIV used to be a death sentence, but now we have effective treatments and prophylactics. What's the PrEP equivalent for buffer overflows? There isn't one.

stkdump 3y ago
Oh, there are lots of PrEP equivalents. For example NX. Or virtual memory more in general. Or static analysis. Etc etc. If you think the modern ecosystem is as memory bug prone as it was in the 80s, you are being incredibly naive.

hurril 3y ago

I'm new to properly native languages, but having worked with Rust for 6 months, I've yet to encounter a single crash that wasn't on part of my error handling. I _love_ C and I've written one C program every year for the last decade or two. I generally write something really stupid, but there's going to be crashes that "prints the stack pants." As in: I'll fudge up returning the stack from a function, basically. This proves nothing, of course. But Rust won't even let me fudge things up that way. This means that I have more time to spend fixing those other classes of bugs and that is the win!

stkdump 3y ago
I have been full time in C++ development for >15 years. I can count the number of times I had memory correctness issues that weren't discovered and fixed trivially on one hand, all of them very early in my career. As your adage, of course mine doesn't prove anything.
- lpapez 3y ago
  I don't want to sound like I'm downplaying your carreer, but what kinds of projects did you work on for 15 years to have an experience this positive? For instance I find it incredible that you never had to debug and workaround a third party vendor DLL that you didn't have source for but that was leaking memory like crazy. This is the just one example of something that can be "fixed trivially" as you don't have source to modify, and is extremely common in some fields (i.e. embedded)
  - stkdump 3y ago
    I have been working on a monorepo C++ codebase with on the order of 1000 person years of development on it. And no, we didn't have major issues with memory leaks either. About on par with what I have seen in garbage collected languages. RAII works quite good most of the time.
    - lpapez 3y ago
      I take it that your project being a monorepo means you have access to the code and can change it when deemed neccessary? I get how that would be characterized as "trivially fixable", but I assure you that this is not the kind of projects people complain about when they discuss memory safety issues. Consider that some people need to send emails to vendor companies begging them to stop segfaulting, writing the stack or leaking memory. You're lucky if it gets fixed in a few months, because that means you wouldn't have to seek alternatives which would be even more time consuming. In conclusion, there are many people out there dealing with memory safety issues which are anything but "trivially fixable".

pjmlp 3y ago

It isn't modern, UNIX folks decided to ignore what was being done outside Bell Labs. Had UNIX not been free beer, history would have been quite different for C and C++.

imtringued 3y ago

Your analogy would work if every person having sex gets HIV. Buffer overflows are deeply rooted into C to the point that in the past some standard functions made buffer overflows mandatory.