3 ms·

C and C++ are really versatile, why are there no safe libraries for them (or are there?). If you want to make buffer overflows impossible then add a library th

by rapjr9 5y ago

C and C++ are really versatile, why are there no safe libraries for them (or are there?). If you want to make buffer overflows impossible then add a library that does so and use it. If you want safer memory handling use a library. Or extend C and C++ with standard libraries that are safer to use. Java is implemented in C so anything Java can do, C can do. Many languages are actually implemented in C. What is this fascination with creating a new language every time we want to add some features? Is it the fame of creating and naming your own computer language? From a security perspective creating a new language reduces security because it will never have been as thoroughly vetted as the old languages.

roca 5y ago
Because safety requires that the language prevent you from doing things and libraries don't have much ability to do that. Example: C++ shared_ptr gives you reference counting which helps prevent use-after-free errors. However, shared_ptr can't stop you getting a raw pointer or reference to the underlying object, which can then be used to trigger a use-after-free bug.
staticassertion 5y ago
Saying that Java is safe therefor you can write safe C is not actually sensible. The JVM is a virtual machine that runs user's programs, and those programs are in a memory safe language. That doesn't mean the JVM is memory safe... at all. It's like saying "llvm is in C++, and llvm is used to compile Rust, therefor C++ is as safe as Rust". It's just not a tractable argument. As for the rest of your post, sure, you can create a new revision of C/C++ that's memory safe - feel free to do so. It'll basically be a new language, but that's fine and has nothing to do with the parent's point, which is that we should incentivize memory safety - they didn't say it had to be a new language. As for why people don't take that approach, it's because: it'll be a massive breaking change, so it's really no different from a completely new language. If you're going to create a completely new language you may as well take the time to fix a bunch of other issues while you're there. edit: The above applies to libraries too. There are libraries that enforce stronger security in C++ (I want to say... IronC++? Something like that), and it basically ends up being, give or take, the cognitive overhead of a new language, but with the added bonus of no one actually using it. > From a security perspective creating a new language reduces security because it will never have been as thoroughly vetted as the old languages. This is unsubstantiated, and I highly doubt it is the case.
- h_anna_h 5y ago
  You can actually make a safe C implementation without creating a whole new language, see my other post https://news.ycombinator.com/item?id=27969373 https://news.ycombinator.com/item?id=27969373

by rapjr9 5y ago

roca 5y ago

Because safety requires that the language prevent you from doing things and libraries don't have much ability to do that. Example: C++ shared_ptr gives you reference counting which helps prevent use-after-free errors. However, shared_ptr can't stop you getting a raw pointer or reference to the underlying object, which can then be used to trigger a use-after-free bug.

staticassertion 5y ago

Saying that Java is safe therefor you can write safe C is not actually sensible. The JVM is a virtual machine that runs user's programs, and those programs are in a memory safe language. That doesn't mean the JVM is memory safe... at all. It's like saying "llvm is in C++, and llvm is used to compile Rust, therefor C++ is as safe as Rust". It's just not a tractable argument. As for the rest of your post, sure, you can create a new revision of C/C++ that's memory safe - feel free to do so. It'll basically be a new language, but that's fine and has nothing to do with the parent's point, which is that we should incentivize memory safety - they didn't say it had to be a new language. As for why people don't take that approach, it's because: it'll be a massive breaking change, so it's really no different from a completely new language. If you're going to create a completely new language you may as well take the time to fix a bunch of other issues while you're there. edit: The above applies to libraries too. There are libraries that enforce stronger security in C++ (I want to say... IronC++? Something like that), and it basically ends up being, give or take, the cognitive overhead of a new language, but with the added bonus of no one actually using it. > From a security perspective creating a new language reduces security because it will never have been as thoroughly vetted as the old languages. This is unsubstantiated, and I highly doubt it is the case.

h_anna_h 5y ago
You can actually make a safe C implementation without creating a whole new language, see my other post https://news.ycombinator.com/item?id=27969373 https://news.ycombinator.com/item?id=27969373