3 ms·

> I cannot consistently write safe C/C++ code. I'm not sure how to interpret what this means. What do "consistent" and "safe" mean? Is safety about not corrupt

> I cannot consistently write safe C/C++ code. I'm not sure how to interpret what this means. What do "consistent" and "safe" mean? Is safety about not corrupting program data? Even when dealing with Python arrays, I can end up corrupting my arrays one way or another (off by one, race conditions, etc.). Is "consistent" about going days without a bug? Because I can't do that in any language. If not, what do these mean? It'd be really nice to know what other languages he can write safe code in, so we can have something to compare to.

cbanek 9y ago
> Is "consistent" about going days without a bug? Because I can't do that in any language. Amen to that. Even when I feel like I cover most of the cases, the sands of time will slowly eat away at the foundation, things become deprecated, and new error conditions added all the time.
danieldk 9y ago
I think it is clear what he means from the remainder of the blog post: I see a lot of people assert that safety issues (leading to exploitable bugs) It is obvious that he is referring to typical C/C++ safety issues buffer overflows, use after free, etc. Even when dealing with Python arrays You can introduce security vulnerabilities in any programming language. But safe languages exclude a host of memory-related vulnerabilities, which are a substantial proportion of all vulnerabilities. Safety is not binary, some languages provide better safety or better means to model domain data safely than other languages.
continuational 9y ago
Consistent as in you can do it while focusing on solving business problems, instead of only when safety is the primary thing you're concentrating on. Safe as in a minor bug is unlikely to be an exploitable security hole.
simias 9y ago
You can have "safe" buggy code as long as you avoid the subset of bugs that can open a security vulnerability. It's possible to make such a mistake in any language but some make it harder than others. C's laissez-faire approach to memory management makes it very easy to introduce a small bug that leads to a major security vulnerability. Indexing out of bounds in python throws an exception. Indexing out of bounds in C triggers the dreaded "undefined behaviour". Here be dragons.
pjmlp 9y ago
Of course every programming language is not perfect, including its library and related implementations. In all of them is possible to introduce logical bugs. The problem with C and its derived languages is that not only one has the logical bugs common to all programming languages, there are the memory corruption and UB introduced bugs to worry about as well. While one can think as being super competent, make use of all tools to reduce such error cases, there are always situations where such errors get introduced due to fatigue, project pressure, continuous interrupts. Additionally since most of us don't work alone, the actual code quality is an average of everyone that has ever worked on the code, and not everyone shares the same goals regarding quality of their work. I share the feeling with the author, always tried to follow C and C++ best practices, when coding in C I adopted or evangelized tooling, safety standards or known books that lead to safer code. Yet, like everyone else I had my share of memory corruption issues back on my C and C++ days. One anecdote was trying to find out a memory leak that was bringing down a server in production, with the customer calling technical support every single day. It took one week to track it down, and it wasn't something I would advise anyone to experiment.
- danieltillett 9y ago
  The good thing about C is there is an amazing tool support that can make it as safe as any other language. The bad thing about C is that most developers don’t know about (or don’t use) all the tools.
  - clarry 9y ago
    They don't even use their compiler.. case in point: https://news.ycombinator.com/item?id=14787072 https://news.ycombinator.com/item?id=14787072 Of course they always just blame the language. Like the language needs to be responsible for the implementation and its proper use.
    - kbenson 9y ago
      Any tool that requires special knowledge to use safely rather than defaulting to safe operation and requiring special knowledge to use unsafely is poorly designed. If the design specification for that class or tools encourages or requires that, it's a poor specification indeed.

cbanek 9y ago

> Is "consistent" about going days without a bug? Because I can't do that in any language. Amen to that. Even when I feel like I cover most of the cases, the sands of time will slowly eat away at the foundation, things become deprecated, and new error conditions added all the time.

danieldk 9y ago

I think it is clear what he means from the remainder of the blog post: I see a lot of people assert that safety issues (leading to exploitable bugs) It is obvious that he is referring to typical C/C++ safety issues buffer overflows, use after free, etc. Even when dealing with Python arrays You can introduce security vulnerabilities in any programming language. But safe languages exclude a host of memory-related vulnerabilities, which are a substantial proportion of all vulnerabilities. Safety is not binary, some languages provide better safety or better means to model domain data safely than other languages.

continuational 9y ago

Consistent as in you can do it while focusing on solving business problems, instead of only when safety is the primary thing you're concentrating on. Safe as in a minor bug is unlikely to be an exploitable security hole.

simias 9y ago

You can have "safe" buggy code as long as you avoid the subset of bugs that can open a security vulnerability. It's possible to make such a mistake in any language but some make it harder than others. C's laissez-faire approach to memory management makes it very easy to introduce a small bug that leads to a major security vulnerability. Indexing out of bounds in python throws an exception. Indexing out of bounds in C triggers the dreaded "undefined behaviour". Here be dragons.

pjmlp 9y ago

Of course every programming language is not perfect, including its library and related implementations. In all of them is possible to introduce logical bugs. The problem with C and its derived languages is that not only one has the logical bugs common to all programming languages, there are the memory corruption and UB introduced bugs to worry about as well. While one can think as being super competent, make use of all tools to reduce such error cases, there are always situations where such errors get introduced due to fatigue, project pressure, continuous interrupts. Additionally since most of us don't work alone, the actual code quality is an average of everyone that has ever worked on the code, and not everyone shares the same goals regarding quality of their work. I share the feeling with the author, always tried to follow C and C++ best practices, when coding in C I adopted or evangelized tooling, safety standards or known books that lead to safer code. Yet, like everyone else I had my share of memory corruption issues back on my C and C++ days. One anecdote was trying to find out a memory leak that was bringing down a server in production, with the customer calling technical support every single day. It took one week to track it down, and it wasn't something I would advise anyone to experiment.

danieltillett 9y ago
The good thing about C is there is an amazing tool support that can make it as safe as any other language. The bad thing about C is that most developers don’t know about (or don’t use) all the tools.
- clarry 9y ago
  They don't even use their compiler.. case in point: https://news.ycombinator.com/item?id=14787072 https://news.ycombinator.com/item?id=14787072 Of course they always just blame the language. Like the language needs to be responsible for the implementation and its proper use.
  - kbenson 9y ago
    Any tool that requires special knowledge to use safely rather than defaulting to safe operation and requiring special knowledge to use unsafely is poorly designed. If the design specification for that class or tools encourages or requires that, it's a poor specification indeed.