4 ms·

I agree, and I'd like to add that its not just this particular author, but most people who criticise C about it's "insecurities" use sloppy code when they criti

by spoiler 11y ago

I agree, and I'd like to add that its not just this particular author, but most people who criticise C about it's "insecurities" use sloppy code when they criticise C, which always bothers me. I'm far from being a C fan (I'm also a Ruby fanboy), but programming languages aren't safe, only code can be safe, and that depends entirely on the developer. Yes, it's "easier" to introduce some bugs in C than Ruby (or Go, or whatever), but that's because whoever wrote that code with the bug didn't know C well enough. Is that C's fault? Same can be said about any language, really. If you don't know that String#match returns nil on unsuccessful matches and try to call MatchData#[], you'll get a NPE (something along the lines of "undefined method `[]' for NilClass"). This is very similar to dereferencing a NULL pointer in C[1]. [1]: I know dereferencing a NULL pointer in C is undefined behaviour, but your program will crash—if you're lucky enough—when you try to work with NULL pointers when you don't expect them.

dbaupp 11y ago
This is nonsense. C has a very weak type system and very weak runtime guarantees, making it much easier to introduce problems with no indication that something's up. Other languages with strong type systems and/or stronger runtime checks eliminate large classes of bugs that are very easy to trigger in C. So, yes, it is C's "fault" that it doesn't protect against classes of bugs that many other languages do. Sure, those languages have some of the same bugs that C does, but they're missing most of the very worst ones and that's really powerful. For example, a garbage collector protects against accessing dangling pointers: it's just not something the programmer has to worry about at all. Rejecting cricitisms of C's safety inadequacies with "just code better"/"just learn the language better" doesn't work in practice: there have been too many high-profile vulnerabilities in C software, many of which would've been much harder to trigger in other languages.
- cremno 11y ago
  >C has a very weak type system and very weak runtime guarantees, making it much easier to introduce problems with no indication that something's up. Here's an interesting example I've stumbled upon a few weeks ago: https://stackoverflow.com/questions/31037149/type-safety-for-complex-arithmetic-in-c99/ https://stackoverflow.com/questions/31037149/type-safety-for... float _Complex -> float doesn't require any diagnostic even though the imaginary component is (silently) discarded. Clang has one (not enabled by default or -Wall/-Wextra) however current GCC versions haven't.
  - asveikau 11y ago
    I'm sure both people using C99 support for complex numbers are really bothered by this.
    - stephencanon 11y ago
      Nope, never been a problem. Can't speak for the other guy.
      - FreeFull 11y ago
        Never been a problem for me either.
- nathanb 11y ago
  I think you're discounting the fact that the software with the bugs was written in C precisely because C was a better fit than the other languages which offered greater protection. I'm not saying (and have never said) that C is better than other languages for every problem. I'm just saying that I read too many articles about the "problems" with C that Stupid C Programmers must not realize since we keep using it where the author of the article hasn't bothered to understand why programs are written in C in the first place.
pcwalton 11y ago
The undefined behavior of C and C++ results in remote code execution to a degree completely unmatched by other languages. Examples of dangerous UB in C always use deliberately sloppy code for pedagogical reasons. For real-world examples of problems, look at the CVE database.
- mcguire 11y ago
  How much of this is due to problems with C or C++, and how much is simply due to a lack of other languages for systems programming? And yes, a major complaint of mine is using C or C++ when you don't absolutely have to.
  - pjmlp 11y ago
    > How much of this is due to problems with C or C++, and how much is simply due to a lack of other languages for systems programming? You mean lack of Algol, Mesa, Modula-2, Modula-3, Ada, Oberon, Oberon-2, Component Pascal, Object Pascal, Delphi, .... ? C became ubiquous when UNIX got adopted as the enterprise OS, slowly replacing the mainframes. Like JavaScript in browsers or Objective-C in iOS, targeting UNIX meant using C, back in the day companies would pay for UNIX SDKs. No sane company would buy another compiler when they already had to pay for a C one, the official language. The other OS vendors started to offer C compilers in their tools to ease the transition between the new UNIX workstations and their other OS. So alternative saner systems programming languages wither way as C grew stronger and now we are with this problem.
    - mcguire 11y ago
      "Lack of other languages" was poorly worded. I'm sorry. What I meant was that, after the spread of Unix and C, C is the most common systems language in production. (Before the spread of C, I believe assembly was the most common systems language(s).) I suspect that any systems language would have a bad reputation if it were used (and over-used) as much as C.
  - ufo 11y ago
    Lots of languages around the time C came out had array bounds checks at runtime. C has a hard time doing that because of pointed and arrays being (mostly) interchangeable.
freyr 11y ago
Since the author of the post is also an author of LLVM, clang, and Swift, and the director of developer tools at Apple, he certainly understands the difference between sloppy and non-sloppy code, but he also knows that sloppy code is a reality and undefined behavior is dangerous. So we can make everyone a better programmer, or we can make better languages, or we can throw in the towel and say things are good enough. I think he's suggesting the correct path.
MaulingMonkey 11y ago
> most people who criticise C about it's "insecurities" use sloppy code when they criticise C, which always bothers me If you're really really lucky, your coworkers will only write sloppy code by accident. But unless you're only working on toy projects, statistics will catch up to you and sloppy code will happen. To err is human. By NASA standards, I suspect most of your code has been written "sloppy". As has most of mine. > but programming languages aren't safe, only code can be safe, and that depends entirely on the developer. Languages can be safe in the sense that they can force code to be safe in specific ways, or at least warn you better with unsafe opt-ins or better static analysis. We agree that the developer is to blame for the thousands of overflow CVEs out there. One developer recognizes they're not an infallible robot, nor are their coworkers, nor is the new intern they're about to hire, and uses the tools at their disposal - static analysis, "safe" languages, etc. - to catch and fix some large percentage of certain mistakes they, and those they work with, make. Another developer scoffs at the first for "blaming their tools" and tries to avoid mistakes with sheer willpower. By not setting up static analysis, maybe they save enough time to do an additional 10-20 code reviews over the course of the project. All else being equal, who will end up with safer code? > Yes, it's "easier" to introduce some bugs in C than Ruby (or Go, or whatever), but that's because whoever wrote that code with the bug didn't know C well enough. If this is true, nobody knows C well enough. Find me a programmer who's written a sufficiently large C project without a single bug, and I will worship them as a living god. > Is that C's fault? Same can be said about any language, really. I don't care about fault, per se. But sure, let's blame C. And every other language. Let's not blind ourselves against their faults, and the possible ways we might improve them, and the possible ways we might adapt ourselves to them. Let's not saddle ourselves with stone axes for the rest of our lives. > If you don't know that String#match returns nil on unsuccessful matches and try to call MatchData#[], you'll get a NPE (something along the lines of "undefined method `[]' for NilClass"). This is very similar to dereferencing a NULL pointer in C[1]. Hence the point of talks such as "Null References: The Billion Dollar Mistake", and why some languages are designed to avoid letting you access potentially null/nil/nothing variables without checking that they aren't first.
geofft 11y ago
> Yes, it's "easier" to introduce some bugs in C than Ruby (or Go, or whatever), but that's because whoever wrote that code with the bug didn't know C well enough. Is that C's fault? Same can be said about any language, really. I thought the promise of computers is that we didn't need to have smart people working on repetitive, boring, error-prone jobs. And yes, there's a line between languages like C, Ruby, Python, Objective-C, etc. on one hand that don't actively try to make bugs hard, and Ada, Rust, Haskell, Ur, etc. on the other. That line is not particularly lined up with something like interpreted vs. compiled or old vs. new, and if you look for the line there, you won't see it.
vardump 11y ago
I don't know anyone who can write proper, secure, bug free C code in multithreaded environment. Some people, such as DJB [1] do get pretty close, though. Much less those who can do same with C++. But when you have larger teams, it gets even harder. People just think so differently and misunderstand intentions without realizing. I did think I could do that in my twenties. 15+ years later I have a lot more respect for C. [1]: http://cr.yp.to/qmail/guarantee.html http://cr.yp.to/qmail/guarantee.html

by spoiler 11y ago

dbaupp 11y ago

This is nonsense. C has a very weak type system and very weak runtime guarantees, making it much easier to introduce problems with no indication that something's up. Other languages with strong type systems and/or stronger runtime checks eliminate large classes of bugs that are very easy to trigger in C. So, yes, it is C's "fault" that it doesn't protect against classes of bugs that many other languages do. Sure, those languages have some of the same bugs that C does, but they're missing most of the very worst ones and that's really powerful. For example, a garbage collector protects against accessing dangling pointers: it's just not something the programmer has to worry about at all. Rejecting cricitisms of C's safety inadequacies with "just code better"/"just learn the language better" doesn't work in practice: there have been too many high-profile vulnerabilities in C software, many of which would've been much harder to trigger in other languages.

cremno 11y ago
>C has a very weak type system and very weak runtime guarantees, making it much easier to introduce problems with no indication that something's up. Here's an interesting example I've stumbled upon a few weeks ago: https://stackoverflow.com/questions/31037149/type-safety-for-complex-arithmetic-in-c99/ https://stackoverflow.com/questions/31037149/type-safety-for... float _Complex -> float doesn't require any diagnostic even though the imaginary component is (silently) discarded. Clang has one (not enabled by default or -Wall/-Wextra) however current GCC versions haven't.
- asveikau 11y ago
  I'm sure both people using C99 support for complex numbers are really bothered by this.
  - stephencanon 11y ago
    Nope, never been a problem. Can't speak for the other guy.
    - FreeFull 11y ago
      Never been a problem for me either.
nathanb 11y ago
I think you're discounting the fact that the software with the bugs was written in C precisely because C was a better fit than the other languages which offered greater protection. I'm not saying (and have never said) that C is better than other languages for every problem. I'm just saying that I read too many articles about the "problems" with C that Stupid C Programmers must not realize since we keep using it where the author of the article hasn't bothered to understand why programs are written in C in the first place.

pcwalton 11y ago

The undefined behavior of C and C++ results in remote code execution to a degree completely unmatched by other languages. Examples of dangerous UB in C always use deliberately sloppy code for pedagogical reasons. For real-world examples of problems, look at the CVE database.

mcguire 11y ago
How much of this is due to problems with C or C++, and how much is simply due to a lack of other languages for systems programming? And yes, a major complaint of mine is using C or C++ when you don't absolutely have to.
- pjmlp 11y ago
  > How much of this is due to problems with C or C++, and how much is simply due to a lack of other languages for systems programming? You mean lack of Algol, Mesa, Modula-2, Modula-3, Ada, Oberon, Oberon-2, Component Pascal, Object Pascal, Delphi, .... ? C became ubiquous when UNIX got adopted as the enterprise OS, slowly replacing the mainframes. Like JavaScript in browsers or Objective-C in iOS, targeting UNIX meant using C, back in the day companies would pay for UNIX SDKs. No sane company would buy another compiler when they already had to pay for a C one, the official language. The other OS vendors started to offer C compilers in their tools to ease the transition between the new UNIX workstations and their other OS. So alternative saner systems programming languages wither way as C grew stronger and now we are with this problem.
  - mcguire 11y ago
    "Lack of other languages" was poorly worded. I'm sorry. What I meant was that, after the spread of Unix and C, C is the most common systems language in production. (Before the spread of C, I believe assembly was the most common systems language(s).) I suspect that any systems language would have a bad reputation if it were used (and over-used) as much as C.
- ufo 11y ago
  Lots of languages around the time C came out had array bounds checks at runtime. C has a hard time doing that because of pointed and arrays being (mostly) interchangeable.

freyr 11y ago

Since the author of the post is also an author of LLVM, clang, and Swift, and the director of developer tools at Apple, he certainly understands the difference between sloppy and non-sloppy code, but he also knows that sloppy code is a reality and undefined behavior is dangerous. So we can make everyone a better programmer, or we can make better languages, or we can throw in the towel and say things are good enough. I think he's suggesting the correct path.

MaulingMonkey 11y ago

> most people who criticise C about it's "insecurities" use sloppy code when they criticise C, which always bothers me If you're really really lucky, your coworkers will only write sloppy code by accident. But unless you're only working on toy projects, statistics will catch up to you and sloppy code will happen. To err is human. By NASA standards, I suspect most of your code has been written "sloppy". As has most of mine. > but programming languages aren't safe, only code can be safe, and that depends entirely on the developer. Languages can be safe in the sense that they can force code to be safe in specific ways, or at least warn you better with unsafe opt-ins or better static analysis. We agree that the developer is to blame for the thousands of overflow CVEs out there. One developer recognizes they're not an infallible robot, nor are their coworkers, nor is the new intern they're about to hire, and uses the tools at their disposal - static analysis, "safe" languages, etc. - to catch and fix some large percentage of certain mistakes they, and those they work with, make. Another developer scoffs at the first for "blaming their tools" and tries to avoid mistakes with sheer willpower. By not setting up static analysis, maybe they save enough time to do an additional 10-20 code reviews over the course of the project. All else being equal, who will end up with safer code? > Yes, it's "easier" to introduce some bugs in C than Ruby (or Go, or whatever), but that's because whoever wrote that code with the bug didn't know C well enough. If this is true, nobody knows C well enough. Find me a programmer who's written a sufficiently large C project without a single bug, and I will worship them as a living god. > Is that C's fault? Same can be said about any language, really. I don't care about fault, per se. But sure, let's blame C. And every other language. Let's not blind ourselves against their faults, and the possible ways we might improve them, and the possible ways we might adapt ourselves to them. Let's not saddle ourselves with stone axes for the rest of our lives. > If you don't know that String#match returns nil on unsuccessful matches and try to call MatchData#[], you'll get a NPE (something along the lines of "undefined method `[]' for NilClass"). This is very similar to dereferencing a NULL pointer in C[1]. Hence the point of talks such as "Null References: The Billion Dollar Mistake", and why some languages are designed to avoid letting you access potentially null/nil/nothing variables without checking that they aren't first.

geofft 11y ago

> Yes, it's "easier" to introduce some bugs in C than Ruby (or Go, or whatever), but that's because whoever wrote that code with the bug didn't know C well enough. Is that C's fault? Same can be said about any language, really. I thought the promise of computers is that we didn't need to have smart people working on repetitive, boring, error-prone jobs. And yes, there's a line between languages like C, Ruby, Python, Objective-C, etc. on one hand that don't actively try to make bugs hard, and Ada, Rust, Haskell, Ur, etc. on the other. That line is not particularly lined up with something like interpreted vs. compiled or old vs. new, and if you look for the line there, you won't see it.

vardump 11y ago

I don't know anyone who can write proper, secure, bug free C code in multithreaded environment. Some people, such as DJB [1] do get pretty close, though. Much less those who can do same with C++. But when you have larger teams, it gets even harder. People just think so differently and misunderstand intentions without realizing. I did think I could do that in my twenties. 15+ years later I have a lot more respect for C. [1]: http://cr.yp.to/qmail/guarantee.html http://cr.yp.to/qmail/guarantee.html