6 ms·

There is a lot of scaremongery around C.... don't believe it. If you know what you're doing (and you should) then C is the best tool for the job.

Profan 10y ago
Best tool is a stretch, it's a tool. If we can get tools like Rust which have better memory safety guarantees while offering much of the same performance, then hell, why not? It's easy to see why just by looking at the hundreds of CVE's throughout the years, often caused by memory unsafe operations. Not that I don't like C, but there's many better alternatives out there. And this is coming from someone who stubbornly sticks to writing D in C-style, but knows what Rust brings to the table.
- TickleSteve 10y ago
  OK, I'm biased as I've got over 20 years in embedded/real-time systems primarily written in C (and C++) and am currently architect for an embedded system containing ~million lines of code and rolling out to tens of millions of units.... (But I'm educated enough to also use Python, Clojure, C# and a variety of other systems). ...and C is currently the best choice for systems like this because of reasons not primarily to do with the language. Currently, if you suggest to use a language other than C you will be laughed out because the only available embedded guys are C based. Yes, momentum counts and C has massive momentum. There are also issues such as toolchains and tooling, familiarity, community, and of course the massive existing set of libraries, codebases and knowledge. Basically, C is 'good enough'. (although Rust is interesting and on the horizon, its a long way off yet). Although technically a better language, C's shortcomings are greatly exaggerated, for example memory management. In general this is not an issue in bare metal embedded systems as you don't have a heap, everything is statically allocated by design. There are many flaws in the C language (as in every language), but in day-to-day use, they are very easy to manage. So... don't believe the (bad) hype.
  - nickpsecurity 10y ago
    "There are also issues such as toolchains and tooling, familiarity, community, and of course the massive existing set of libraries, codebases and knowledge." Social and economic factors that we C opponents say are why it remains and is often the pragmatic choice. These in no way show C language itself was well-designed, superior, etc. Just show how going mainstream can make things more practical. They did a great job on that part.
    - TickleSteve 10y ago
      Completely agree. TBH, my ideal language for this job would probably be Rust, but that is just not a mature enough ecosystem currently. Don't get me wrong, I would consider myself a C proponent currently, but I would love to see change in a Rust-like direction. Despite you classing yourself as a C-opponent, I suspect we agree more than disagree.
      - nickpsecurity 10y ago
        Probably. I think you're a pragmatist rather than a true believer. ;) Btw, what do you think of a reboot of Modula-2, Modula-3, or just Ada/SPARK? Your opinion on them would be interesting given your background. Closest thing to Modula's that's actively developed is Astrobe Oberon for embedded. https://en.wikipedia.org/wiki/Modula-3 https://en.wikipedia.org/wiki/Modula-3 http://www.astrobe.com/Oberon.htm http://www.astrobe.com/Oberon.htm
        TickleSteve 10y ago
        (Certainly a pragmatist) I started off with Turbo Pascal before graduating to Turbo C, so I do have a fondness for the Pascal family of languages. I also love type-safety.... TBH, I would prefer a hypothetical "fix" for the C language that improved type strictness/safety over "fixes" for resource/memory management issues which I consider should be bread and butter for any software engineer. So in that, I do not like large runtimes or garbage collection, more visibility to what the machine is really doing is needed. GC systems are also not predictable enough, deterministic runtime is absolutely essential to making reliable software. I have poked my nose around Modula-2 in the past, but C took over for me personally. ADA I consider to be far to heavyweight for anything serious (and thats after being in a company that used it extensively in the defence world, tho I never had to touch it myself) Currently Rust is my best hope for the future.... but C has survived well IMO.
pcwalton 10y ago
> If you know what you're doing (and you should) then C is the best tool for the job. Empirically, nobody knows what they're doing, if "knowing what you're doing" is defined as "writing large-scale C code without memory safety problems". I hear a lot from C and C++ enthusiasts that there are lots of programmers out there who always write correct C and C++ code, and therefore we don't need new languages. But I've never found one of those programmers. Can you name one?
- TickleSteve 10y ago
  (see the reply to the above response). Basically, in day-to-day use, the flaws in the language are easily manageable. Resource (memory) management is a skill that should be a given. Yes, there are well publicised failures in this regard, but consider the number of problems versus the actual number of lines of code written.
  - pcwalton 10y ago
    > Yes, there are well publicised failures in this regard, but consider the number of problems versus the actual number of lines of code written. I think that's a pretty misleading metric when you take into account: (1) widely used codebases constantly increase in size constantly; (2) it only takes one exploitable mistake for an attacker to achieve remote code execution. One exploitable vulnerability per 10,000 lines means 1,200 remote code execution flaws in a codebase the size of Chromium.
- jjnoakes 10y ago
  No one "always writes correct large-scale code". I have worked with many who write large-scale C and C++ code with no undefined behavior. Is that what you meant?
  - pcwalton 10y ago
    Yes. I've never seen it. All large-scale C and C++ codebases I've ever seen, from large companies to small ones, have had memory safety/undefined behavior problems [1]. If "just hire better programmers" were a workable solution, surely one company out of {Google, Apple, Microsoft, Facebook} would have succeeded at that strategy by now. It's very easy to write C and C++ code that looks like it's free of undefined behavior, but in every case I've seen they end up falling when attackers actively try to look for problems. [1]: Maybe qmail is the one exception, though even that had a famous debate related to overflow.
nickpsecurity 10y ago
The military and defense contractors did empirical studies of various programming languages and their defect rates to put that to the test. That was mainly in 80's and 90's. They compared C, C++, Ada, and Fortran mainly. C usually had double the defects of the rest and with more severity despite pro's writing it. Ada usually outdid all of them with one showing Ada and C++ developers having same defect rate. So, when we use evidence instead of feelings, what you said is a myth that's been debunked repeatedly in many ways for decades. And, yet, people repeat it. No, C use usually results in problems that safer, systems languages before and after it had less or none of. Despite professionals using it. The solid code is always an outlier. Most amusing thing is Thompson and Ritchie, with help from Pike, later designed what they thought was perfect language with perfect set of features. The result, Go, was basically like Algol subsets that preceded C mixed with Pascal developed around same time. But, C compiled and ran on a PDP-11 fast. So, it's the best. ;)
- TickleSteve 10y ago
  Yes I remember the studies (and have done my fair share of defence s/w). And I am not claiming that C is the best tool for the job because of the language.... its because of the 'environmental' factors, human resources, community, momentum, codebases, portability, etc. I whole-heartedly agree that there are better languages out there, but the fact remains that the flaws in C are easily managed. It would also be interesting to produce a study of the use of C specifically in embedded systems where the style of code is very much different than large desktop systems (i.e. much less heap usage and dynamic memory allocation for example).
  - nickpsecurity 10y ago
    "And I am not claiming that C is the best tool for the job because of the language.... its because of the 'environmental' factors, human resources, community, momentum, codebases, portability, etc." I agreed with you on that in another comment. Yep. It's also why NASA often uses it. The tooling covers dark corners pretty well these days. "It would also be interesting to produce a study of the use of C specifically in embedded systems where the style of code is very much different than large desktop systems (i.e. much less heap usage and dynamic memory allocation for example)." I'd love to replicate the old studies on modern languages with modern tooling for both systems programming and the embedded subsets like MISRA. We'd definitely learn some stuff from that. Further, I'd like to see specific metrics like in Ada/SPARK/CbyC example below on where defects were introduced or corrected with each technique and phase of lifecycle. Would tell us how low-level features, subset rules, and tooling interact with accurate assessment of how much problems they pose for real instead of in theory. http://www.sis.pitt.edu/jjoshi/Devsec/CorrectnessByConstruction.pdf http://www.sis.pitt.edu/jjoshi/Devsec/CorrectnessByConstruct...

Profan 10y ago

Best tool is a stretch, it's a tool. If we can get tools like Rust which have better memory safety guarantees while offering much of the same performance, then hell, why not? It's easy to see why just by looking at the hundreds of CVE's throughout the years, often caused by memory unsafe operations. Not that I don't like C, but there's many better alternatives out there. And this is coming from someone who stubbornly sticks to writing D in C-style, but knows what Rust brings to the table.

TickleSteve 10y ago
OK, I'm biased as I've got over 20 years in embedded/real-time systems primarily written in C (and C++) and am currently architect for an embedded system containing ~million lines of code and rolling out to tens of millions of units.... (But I'm educated enough to also use Python, Clojure, C# and a variety of other systems). ...and C is currently the best choice for systems like this because of reasons not primarily to do with the language. Currently, if you suggest to use a language other than C you will be laughed out because the only available embedded guys are C based. Yes, momentum counts and C has massive momentum. There are also issues such as toolchains and tooling, familiarity, community, and of course the massive existing set of libraries, codebases and knowledge. Basically, C is 'good enough'. (although Rust is interesting and on the horizon, its a long way off yet). Although technically a better language, C's shortcomings are greatly exaggerated, for example memory management. In general this is not an issue in bare metal embedded systems as you don't have a heap, everything is statically allocated by design. There are many flaws in the C language (as in every language), but in day-to-day use, they are very easy to manage. So... don't believe the (bad) hype.
- nickpsecurity 10y ago
  "There are also issues such as toolchains and tooling, familiarity, community, and of course the massive existing set of libraries, codebases and knowledge." Social and economic factors that we C opponents say are why it remains and is often the pragmatic choice. These in no way show C language itself was well-designed, superior, etc. Just show how going mainstream can make things more practical. They did a great job on that part.
  - TickleSteve 10y ago
    Completely agree. TBH, my ideal language for this job would probably be Rust, but that is just not a mature enough ecosystem currently. Don't get me wrong, I would consider myself a C proponent currently, but I would love to see change in a Rust-like direction. Despite you classing yourself as a C-opponent, I suspect we agree more than disagree.
    - nickpsecurity 10y ago
      Probably. I think you're a pragmatist rather than a true believer. ;) Btw, what do you think of a reboot of Modula-2, Modula-3, or just Ada/SPARK? Your opinion on them would be interesting given your background. Closest thing to Modula's that's actively developed is Astrobe Oberon for embedded. https://en.wikipedia.org/wiki/Modula-3 https://en.wikipedia.org/wiki/Modula-3 http://www.astrobe.com/Oberon.htm http://www.astrobe.com/Oberon.htm
      - TickleSteve 10y ago
        (Certainly a pragmatist) I started off with Turbo Pascal before graduating to Turbo C, so I do have a fondness for the Pascal family of languages. I also love type-safety.... TBH, I would prefer a hypothetical "fix" for the C language that improved type strictness/safety over "fixes" for resource/memory management issues which I consider should be bread and butter for any software engineer. So in that, I do not like large runtimes or garbage collection, more visibility to what the machine is really doing is needed. GC systems are also not predictable enough, deterministic runtime is absolutely essential to making reliable software. I have poked my nose around Modula-2 in the past, but C took over for me personally. ADA I consider to be far to heavyweight for anything serious (and thats after being in a company that used it extensively in the defence world, tho I never had to touch it myself) Currently Rust is my best hope for the future.... but C has survived well IMO.

pcwalton 10y ago

> If you know what you're doing (and you should) then C is the best tool for the job. Empirically, nobody knows what they're doing, if "knowing what you're doing" is defined as "writing large-scale C code without memory safety problems". I hear a lot from C and C++ enthusiasts that there are lots of programmers out there who always write correct C and C++ code, and therefore we don't need new languages. But I've never found one of those programmers. Can you name one?

TickleSteve 10y ago
(see the reply to the above response). Basically, in day-to-day use, the flaws in the language are easily manageable. Resource (memory) management is a skill that should be a given. Yes, there are well publicised failures in this regard, but consider the number of problems versus the actual number of lines of code written.
- pcwalton 10y ago
  > Yes, there are well publicised failures in this regard, but consider the number of problems versus the actual number of lines of code written. I think that's a pretty misleading metric when you take into account: (1) widely used codebases constantly increase in size constantly; (2) it only takes one exploitable mistake for an attacker to achieve remote code execution. One exploitable vulnerability per 10,000 lines means 1,200 remote code execution flaws in a codebase the size of Chromium.
jjnoakes 10y ago
No one "always writes correct large-scale code". I have worked with many who write large-scale C and C++ code with no undefined behavior. Is that what you meant?
- pcwalton 10y ago
  Yes. I've never seen it. All large-scale C and C++ codebases I've ever seen, from large companies to small ones, have had memory safety/undefined behavior problems [1]. If "just hire better programmers" were a workable solution, surely one company out of {Google, Apple, Microsoft, Facebook} would have succeeded at that strategy by now. It's very easy to write C and C++ code that looks like it's free of undefined behavior, but in every case I've seen they end up falling when attackers actively try to look for problems. [1]: Maybe qmail is the one exception, though even that had a famous debate related to overflow.

nickpsecurity 10y ago

The military and defense contractors did empirical studies of various programming languages and their defect rates to put that to the test. That was mainly in 80's and 90's. They compared C, C++, Ada, and Fortran mainly. C usually had double the defects of the rest and with more severity despite pro's writing it. Ada usually outdid all of them with one showing Ada and C++ developers having same defect rate. So, when we use evidence instead of feelings, what you said is a myth that's been debunked repeatedly in many ways for decades. And, yet, people repeat it. No, C use usually results in problems that safer, systems languages before and after it had less or none of. Despite professionals using it. The solid code is always an outlier. Most amusing thing is Thompson and Ritchie, with help from Pike, later designed what they thought was perfect language with perfect set of features. The result, Go, was basically like Algol subsets that preceded C mixed with Pascal developed around same time. But, C compiled and ran on a PDP-11 fast. So, it's the best. ;)

TickleSteve 10y ago
Yes I remember the studies (and have done my fair share of defence s/w). And I am not claiming that C is the best tool for the job because of the language.... its because of the 'environmental' factors, human resources, community, momentum, codebases, portability, etc. I whole-heartedly agree that there are better languages out there, but the fact remains that the flaws in C are easily managed. It would also be interesting to produce a study of the use of C specifically in embedded systems where the style of code is very much different than large desktop systems (i.e. much less heap usage and dynamic memory allocation for example).
- nickpsecurity 10y ago
  "And I am not claiming that C is the best tool for the job because of the language.... its because of the 'environmental' factors, human resources, community, momentum, codebases, portability, etc." I agreed with you on that in another comment. Yep. It's also why NASA often uses it. The tooling covers dark corners pretty well these days. "It would also be interesting to produce a study of the use of C specifically in embedded systems where the style of code is very much different than large desktop systems (i.e. much less heap usage and dynamic memory allocation for example)." I'd love to replicate the old studies on modern languages with modern tooling for both systems programming and the embedded subsets like MISRA. We'd definitely learn some stuff from that. Further, I'd like to see specific metrics like in Ada/SPARK/CbyC example below on where defects were introduced or corrected with each technique and phase of lifecycle. Would tell us how low-level features, subset rules, and tooling interact with accurate assessment of how much problems they pose for real instead of in theory. http://www.sis.pitt.edu/jjoshi/Devsec/CorrectnessByConstruction.pdf http://www.sis.pitt.edu/jjoshi/Devsec/CorrectnessByConstruct...