4 ms·

> As far as memory safety goes, never rely on null terminated strings, allways copy the exact amount of data to a statically defined max, and make the buffer th

> As far as memory safety goes, never rely on null terminated strings, allways copy the exact amount of data to a statically defined max, and make the buffer that holds data have the length max+1 with an extra byte that is allways set to null for every copy into the buffer. For malloc/free, design your code so that malloc and free are in the same function at the beggining and end, and allways run memcheck and valgrind before deploying to production. Aren’t you just proving the author’s point here? Even your fairly simple heuristic that works in most cases is easy to screw up due to a typo / brain fart, and it’s quite likely that even experienced developers will write code that memcheck/valgrind complains about (which is why the tools exist!) So writing memory-safe code in C/C++ is brittle and not easy to do consistently without additional tools and checks. The author’s point wasn’t that it’s impossible or conceptually deep, but that it’s tricky and painstaking work which is easy to mess up.

ActorNightly 6y ago
>Even your fairly simple heuristic that works in most cases is easy to screw up due to a typo / brain fart, This argument can be made for "safer" languages just as easily. Most of the web exploits that exist, like request smuggling, parser abuse, or generic exploit involving a sequence of API calls, are all due to brain farts. At a certain level you have to expect some competency. My main argument is that the competency for writing C code isn't that much higher than for other languages.
- Nursie 6y ago
  > My main argument is that the competency for writing C code isn't that much higher than for other languages. I think that goes against observed reality, and the consequences of these errors are worse in unsafe languages. Look at heartbleed - a bounds-checked language would not have allowed that problem to be anything more than an exception, instead process memory was open for reading.
  - ActorNightly 6y ago
    Easy counterexample: most of the computers worldwide run Linux kernel, which is written in C, and kernel exploits, especially those that are accessible from the web, are significantly rarer compared to the higher level exploits in CRUD APIs or LAMP stacks that work on the http protocol level and the authentication state machines. This argument doesn't make sense. Yes, programmers make mistakes. Yes, they shouldn't make those mistakes. My point is that its not difficult to write safe C code if you follow some basic rules.
    - Nursie 6y ago
      > Easy counterexample: The linux kernel is not really a counterexample here, and neither would I call the decades of security hardening that's gone into it "easy"... > Yes, programmers make mistakes. And in some languages those mistakes have far worse consequences than others, and more types of mistakes are possible. > My point is that its not difficult to write safe C code if you follow some basic rules. Except it is more difficult, for a start because you have more rules and tools needed to make it safe, if that's even possible. As you yourself have said.

ActorNightly 6y ago

>Even your fairly simple heuristic that works in most cases is easy to screw up due to a typo / brain fart, This argument can be made for "safer" languages just as easily. Most of the web exploits that exist, like request smuggling, parser abuse, or generic exploit involving a sequence of API calls, are all due to brain farts. At a certain level you have to expect some competency. My main argument is that the competency for writing C code isn't that much higher than for other languages.

Nursie 6y ago
> My main argument is that the competency for writing C code isn't that much higher than for other languages. I think that goes against observed reality, and the consequences of these errors are worse in unsafe languages. Look at heartbleed - a bounds-checked language would not have allowed that problem to be anything more than an exception, instead process memory was open for reading.
- ActorNightly 6y ago
  Easy counterexample: most of the computers worldwide run Linux kernel, which is written in C, and kernel exploits, especially those that are accessible from the web, are significantly rarer compared to the higher level exploits in CRUD APIs or LAMP stacks that work on the http protocol level and the authentication state machines. This argument doesn't make sense. Yes, programmers make mistakes. Yes, they shouldn't make those mistakes. My point is that its not difficult to write safe C code if you follow some basic rules.
  - Nursie 6y ago
    > Easy counterexample: The linux kernel is not really a counterexample here, and neither would I call the decades of security hardening that's gone into it "easy"... > Yes, programmers make mistakes. And in some languages those mistakes have far worse consequences than others, and more types of mistakes are possible. > My point is that its not difficult to write safe C code if you follow some basic rules. Except it is more difficult, for a start because you have more rules and tools needed to make it safe, if that's even possible. As you yourself have said.