3 ms·

I think Peter Van Der Linden would agree. He states in Deep C Programming that the separation of the compiler from the linter, and I assume by extension semanti

I think Peter Van Der Linden would agree. He states in Deep C Programming that the separation of the compiler from the linter, and I assume by extension semantic analysis tools as well, was a mistake in retrospect. It's good to see that compilers like Clang are bringing them back together in a way. One does have to be more careful when writing C but I don't "blame" C for unsafe code. It's the kind of language that assumes the programmer know what they're doing. In this regard it is very unforgiving.

pjmlp 12y ago
Yes lint does exist since 1979 and Ritchie remarks in his notes that it was already a need back then. The problem got worse when C dialects started to appear outside UNIX without Lint. Or the compiler vendors selling it separately of the compiler. The problem with languages that trust the developer is that they are based on a set of false premises, namely: - the team is composed from top skill developers - the team never changes - everyone knows the whole code base Which are all false in the majority of corporations.
- agentultra 12y ago
  I don't understand your false premises. I've never had C marketed to me as a language that promised safe, perfect code. It does what it says on the tin. However I think you have some false premises: the Linux kernel is huge, has a fairly high turn-over in contributors, and is written in C. Hardly anyone "knows" the entire code base. I've yet to meet anyone who can even name all of the compile switches... some 1000+ of them. Yet it's hard to argue that it's not useful or impossible to contribute to. I'm not a genius and if I can figure it out I'm sure I can teach others. Yes, you can write bad code in C. I don't think you can blame C for human error. There are sins of commission and those of omission and the ANSI C specification documents them both quite well. Designing a language that protected an ignorant and uneducated programmer from making mistakes wasn't one of their goals I'm afraid.
  - pjmlp 12y ago
    There is a big difference between writing C code and C code that is safe from exploits, even Linux isn't immune to it as the daily CVE updates show. http://www.cvedetails.com/vulnerability-list/vendor_id-33/product_id-47/cvssscoremin-7/cvssscoremax-7.99/Linux-Linux-Kernel.html http://www.cvedetails.com/vulnerability-list/vendor_id-33/pr...
    - agentultra 12y ago
      Correct and I don't find this surprising. While the separation of lint from the compiler might have been a mistake made as an early performance trade-off I don't really see how that was a false premise of the philosophy of trusting the programmer. Given the history of trade-offs made in the name of performance it doesn't seem like correctness and safety were big concerns. Maybe they are now and that's why I find the Mirage project interesting... but C still has its uses and I don't blame C for human error. The specification isn't terribly difficult to digest and the tooling is rather good these days.

pjmlp 12y ago

Yes lint does exist since 1979 and Ritchie remarks in his notes that it was already a need back then. The problem got worse when C dialects started to appear outside UNIX without Lint. Or the compiler vendors selling it separately of the compiler. The problem with languages that trust the developer is that they are based on a set of false premises, namely: - the team is composed from top skill developers - the team never changes - everyone knows the whole code base Which are all false in the majority of corporations.

agentultra 12y ago
I don't understand your false premises. I've never had C marketed to me as a language that promised safe, perfect code. It does what it says on the tin. However I think you have some false premises: the Linux kernel is huge, has a fairly high turn-over in contributors, and is written in C. Hardly anyone "knows" the entire code base. I've yet to meet anyone who can even name all of the compile switches... some 1000+ of them. Yet it's hard to argue that it's not useful or impossible to contribute to. I'm not a genius and if I can figure it out I'm sure I can teach others. Yes, you can write bad code in C. I don't think you can blame C for human error. There are sins of commission and those of omission and the ANSI C specification documents them both quite well. Designing a language that protected an ignorant and uneducated programmer from making mistakes wasn't one of their goals I'm afraid.
- pjmlp 12y ago
  There is a big difference between writing C code and C code that is safe from exploits, even Linux isn't immune to it as the daily CVE updates show. http://www.cvedetails.com/vulnerability-list/vendor_id-33/product_id-47/cvssscoremin-7/cvssscoremax-7.99/Linux-Linux-Kernel.html http://www.cvedetails.com/vulnerability-list/vendor_id-33/pr...
  - agentultra 12y ago
    Correct and I don't find this surprising. While the separation of lint from the compiler might have been a mistake made as an early performance trade-off I don't really see how that was a false premise of the philosophy of trusting the programmer. Given the history of trade-offs made in the name of performance it doesn't seem like correctness and safety were big concerns. Maybe they are now and that's why I find the Mirage project interesting... but C still has its uses and I don't blame C for human error. The specification isn't terribly difficult to digest and the tooling is rather good these days.