4 ms·

But language and tooling can protect you from error classes, and when the error class (“memory safety”) factors in up to 70% of security vulnerabilities (by som

But language and tooling can protect you from error classes, and when the error class (“memory safety”) factors in up to 70% of security vulnerabilities (by some estimates,) it makes sense to pay attention to tools which can protect you from those errors, rather than lament the lack of protection for the other 30% or errors, which, by the way, could have just as easily happened in a language without strong memory safety protections.

bobba27 3y ago
70% sounds a bit high but I can accept it. You can do a lot in regards to memory safety also in C / C++ : https://llvm.org/pubs/2006-05-24-SAFECode-BoundsCheck.pdf https://llvm.org/pubs/2006-05-24-SAFECode-BoundsCheck.pdf Anyway. Writing safe code in C is HARD but possible. Especially with good tooling. That is not to say everyone should use C. C is an exceptionally hard language to use safely and correctly and is not for everyone.
- marcus0x62 3y ago
  > 70% sounds a bit high but I can accept it One meta-source for this is Prossimo[0]. They link to multiple vendor reports that range from 60 - 90%. > Writing safe code in C is HARD but possible. Especially with good tooling. I don’t disagree in theory, but I think it is so hard as to be impractical in almost every case. So, other than maintaining a legacy code base, why try at this point when other options are available? 0 - https://www.memorysafety.org/docs/memory-safety/#how-common-are-memory-safety-vulnerabilities https://www.memorysafety.org/docs/memory-safety/#how-common-...
  - hgs3 3y ago
    > So, other than maintaining a legacy code base, why try at this point when other options are available? What options would you recommend in 2024? I write C (not C++) and work on projects that are inherently memory unsafe (the last one required hand-written assembly code). I've explored potential C successors in the past, but have yet to discover one that matches the freedoms, simplicity, ergonomics, and performance of the C language.
    - ttfkam 3y ago
      Zig. It's not as safe as Rust, but it's a hell of a lot better than C while remaining largely interoperable.

bobba27 3y ago

70% sounds a bit high but I can accept it. You can do a lot in regards to memory safety also in C / C++ : https://llvm.org/pubs/2006-05-24-SAFECode-BoundsCheck.pdf https://llvm.org/pubs/2006-05-24-SAFECode-BoundsCheck.pdf Anyway. Writing safe code in C is HARD but possible. Especially with good tooling. That is not to say everyone should use C. C is an exceptionally hard language to use safely and correctly and is not for everyone.

marcus0x62 3y ago
> 70% sounds a bit high but I can accept it One meta-source for this is Prossimo[0]. They link to multiple vendor reports that range from 60 - 90%. > Writing safe code in C is HARD but possible. Especially with good tooling. I don’t disagree in theory, but I think it is so hard as to be impractical in almost every case. So, other than maintaining a legacy code base, why try at this point when other options are available? 0 - https://www.memorysafety.org/docs/memory-safety/#how-common-are-memory-safety-vulnerabilities https://www.memorysafety.org/docs/memory-safety/#how-common-...
- hgs3 3y ago
  > So, other than maintaining a legacy code base, why try at this point when other options are available? What options would you recommend in 2024? I write C (not C++) and work on projects that are inherently memory unsafe (the last one required hand-written assembly code). I've explored potential C successors in the past, but have yet to discover one that matches the freedoms, simplicity, ergonomics, and performance of the C language.
  - ttfkam 3y ago
    Zig. It's not as safe as Rust, but it's a hell of a lot better than C while remaining largely interoperable.