6 ms·

> Defenders of C/C++ frequently note that memory safety bugs aren't a significant percentage of the total bug count, and argue that this means it's not worth th

by gnull 4y ago

> Defenders of C/C++ frequently note that memory safety bugs aren't a significant percentage of the total bug count, and argue that this means it's not worth the hassle This says more about those C++ defenders.

hinkley 4y ago
You can judge a person by the company they keep.
- munificent 4y ago
  Lie down with C++, wake up with bugs.
Gigachad 4y ago
C-nile developers have been making incorrect arguments for a while now. The reality is which almost everyone can see is that memory safe languages are pretty much always what you want to be using for new code. OS and security sensitive components are the prime targets for rewrites in more secure languages. Now Google has put this to the test and has the data to prove it. We should not allow the worlds technology security to be held hostage by a group of people too lazy to adapt with the times.
- saagarjha 4y ago
  > The reality is which almost everyone can see is that memory safe languages are pretty much always what you want to be using for new code. Nitpick, this is not quite true. Memory safe languages are what you should be using in contexts where security and reliability are critical. This is generally the case but there are some contexts where other concerns are genuinely more important. Of course when this is necessary is often misrepresented but these cases do exist.
  - Sirened 4y ago
    writing exploits, for example, is an utter pain in today's safe languages :) C is unmatched in the sheer ease of manipulating raw bytes with some light structuring on top for convenience. I've tried writing exploits in Swift a handful of times but I always gave up after I found myself buried under a pile of UnsafeMutableRawBufferPointers.
    - gnull 4y ago
      You mean, manipulating strings of bytes? Bytes don't have to be memory, you can just use bytestrings in Python or whatever. Raw memory access is something you normally need to create vulnerabilities, not to exploit them :)
      - Sirened 4y ago
        har har :) It's an ergonomics thing, not a "can't" issue. There is a reason I called out Swift in particular—their "unsafe" APIs are so horrid to use that they make you regret doing unsafe things in the first place. Plus, throw in FFI and now you've got an even worse problem because not only are you forced to use the unsafe types, but often a lot of the critical APIs you need to interface with (in *OS exploitation, mach is the worst offender) have such funky types due to their generic nature that you have to go through half a dozen different conversions to get access to the underlying data.
        gnull 4y ago
        I still don't understand why would you prefer raw memory manipulation to bytestring manipulation. If you want, just make a Swift library that will implement the memory like you want but without unsafe raw access (but just a few methods over a byte array). Back in the days when I did CTFs, I used Python for writing binary exploits, never C. https://github.com/hellman/libformatstr https://github.com/hellman/libformatstr You can do something like this, no need to work with raw memory.
        saagarjha 4y ago
        Swift has the advantage that it can directly “speak” C, without any indirection needed. (C can already do this of course.) In particular operations like scanning an address space for things, easily expressing the layout of something, and so on are much easier to do in these languages. In theory you could do the same in Python but it’s often not worth the effort.
- logicchains 4y ago
  >The reality is which almost everyone can see is that memory safe languages are pretty much always what you want to be using for new code. Not everybody is writing security-critical code. For some things productivity and time-to-market is more important and security is not enough of a concern to justify dealing with a language with horrible compile times and a self-righteous, dogmatic community.
  - Gigachad 4y ago
    We probably need to bring in some kind of criminal liability for the companies that only cared about time to market and put their users at risk. After memory safe languages become a bit more battle tested, C/++ needs to be regulated like asbestos.
    - logicchains 4y ago
      Not everybody's building a product that deals with sensitive user data. By your logic all code not written in proof languages should be illegal.
  - foxes 4y ago
    Where has time to market and productivity ever been a factor for C and the C ecosystem? My most "productive" languages have been declarative languages like Haskell (depending on how you measure that). I don't care if it takes an extra few minutes to compile either, amortized away in the long term when you don't have to deal with entire additional classes of bugs to deal with. Also why is security never an important concern? There are a lot of security issues which are self inflicted if you use C. Using something like rust means a lot of issues simply don't exist. The optimal solution.
    - jstimpfle 4y ago
      I spent a considerable amount of time learning Haskell but I always felt like a slave to the language. Oh, you want to do this other simple thing? Try language extension XYZ, but you'll have to learn some more language theory first. Also sorry but the extension isn't compatible with the extensions you're already using, and you need to require a new dependency on the outside interface. There are some things that the language is good at, but at some other things (I think a lot actually) it isn't. At the very least, I wouldn't recommend it for writing a video decoder.
- raxxorraxor 4y ago
  Meh, bad argument. How about you write better code in Rust to replace existing stuff. There is so much more to consider and I think one of Rusts most repellent features is the preaching about its advantages. I definitely has some that are hard to deny. Still... how about just doing it, nobody is held hostage here.
  - steveklabnik 4y ago
    > How about you write better code in Rust to replace existing stuff. No matter what people do, it's never enough for the critics. Many people criticize Rust fans for "rewriting it in Rust"! > how about just doing it People absolutely are. That's what the article is about, even.

by gnull 4y ago

hinkley 4y ago

You can judge a person by the company they keep.

munificent 4y ago
Lie down with C++, wake up with bugs.

Gigachad 4y ago

C-nile developers have been making incorrect arguments for a while now. The reality is which almost everyone can see is that memory safe languages are pretty much always what you want to be using for new code. OS and security sensitive components are the prime targets for rewrites in more secure languages. Now Google has put this to the test and has the data to prove it. We should not allow the worlds technology security to be held hostage by a group of people too lazy to adapt with the times.

saagarjha 4y ago
> The reality is which almost everyone can see is that memory safe languages are pretty much always what you want to be using for new code. Nitpick, this is not quite true. Memory safe languages are what you should be using in contexts where security and reliability are critical. This is generally the case but there are some contexts where other concerns are genuinely more important. Of course when this is necessary is often misrepresented but these cases do exist.
- Sirened 4y ago
  writing exploits, for example, is an utter pain in today's safe languages :) C is unmatched in the sheer ease of manipulating raw bytes with some light structuring on top for convenience. I've tried writing exploits in Swift a handful of times but I always gave up after I found myself buried under a pile of UnsafeMutableRawBufferPointers.
  - gnull 4y ago
    You mean, manipulating strings of bytes? Bytes don't have to be memory, you can just use bytestrings in Python or whatever. Raw memory access is something you normally need to create vulnerabilities, not to exploit them :)
    - Sirened 4y ago
      har har :) It's an ergonomics thing, not a "can't" issue. There is a reason I called out Swift in particular—their "unsafe" APIs are so horrid to use that they make you regret doing unsafe things in the first place. Plus, throw in FFI and now you've got an even worse problem because not only are you forced to use the unsafe types, but often a lot of the critical APIs you need to interface with (in *OS exploitation, mach is the worst offender) have such funky types due to their generic nature that you have to go through half a dozen different conversions to get access to the underlying data.
      - gnull 4y ago
        I still don't understand why would you prefer raw memory manipulation to bytestring manipulation. If you want, just make a Swift library that will implement the memory like you want but without unsafe raw access (but just a few methods over a byte array). Back in the days when I did CTFs, I used Python for writing binary exploits, never C. https://github.com/hellman/libformatstr https://github.com/hellman/libformatstr You can do something like this, no need to work with raw memory.
        saagarjha 4y ago
        Swift has the advantage that it can directly “speak” C, without any indirection needed. (C can already do this of course.) In particular operations like scanning an address space for things, easily expressing the layout of something, and so on are much easier to do in these languages. In theory you could do the same in Python but it’s often not worth the effort.
logicchains 4y ago
>The reality is which almost everyone can see is that memory safe languages are pretty much always what you want to be using for new code. Not everybody is writing security-critical code. For some things productivity and time-to-market is more important and security is not enough of a concern to justify dealing with a language with horrible compile times and a self-righteous, dogmatic community.
- Gigachad 4y ago
  We probably need to bring in some kind of criminal liability for the companies that only cared about time to market and put their users at risk. After memory safe languages become a bit more battle tested, C/++ needs to be regulated like asbestos.
  - logicchains 4y ago
    Not everybody's building a product that deals with sensitive user data. By your logic all code not written in proof languages should be illegal.
- foxes 4y ago
  Where has time to market and productivity ever been a factor for C and the C ecosystem? My most "productive" languages have been declarative languages like Haskell (depending on how you measure that). I don't care if it takes an extra few minutes to compile either, amortized away in the long term when you don't have to deal with entire additional classes of bugs to deal with. Also why is security never an important concern? There are a lot of security issues which are self inflicted if you use C. Using something like rust means a lot of issues simply don't exist. The optimal solution.
  - jstimpfle 4y ago
    I spent a considerable amount of time learning Haskell but I always felt like a slave to the language. Oh, you want to do this other simple thing? Try language extension XYZ, but you'll have to learn some more language theory first. Also sorry but the extension isn't compatible with the extensions you're already using, and you need to require a new dependency on the outside interface. There are some things that the language is good at, but at some other things (I think a lot actually) it isn't. At the very least, I wouldn't recommend it for writing a video decoder.
raxxorraxor 4y ago
Meh, bad argument. How about you write better code in Rust to replace existing stuff. There is so much more to consider and I think one of Rusts most repellent features is the preaching about its advantages. I definitely has some that are hard to deny. Still... how about just doing it, nobody is held hostage here.
- steveklabnik 4y ago
  > How about you write better code in Rust to replace existing stuff. No matter what people do, it's never enough for the critics. Many people criticize Rust fans for "rewriting it in Rust"! > how about just doing it People absolutely are. That's what the article is about, even.