5 ms·

Okay, libraries can't provide new inabilities. But that's why we have linters, static analyzers, style guides, compiler options and warnings, and ultimately cod

by btrask 10y ago

Okay, libraries can't provide new inabilities. But that's why we have linters, static analyzers, style guides, compiler options and warnings, and ultimately code reviews and good taste. I think the big problem (and sometimes benefit) of old languages is their culture. For example, C programmers don't trust anything written since K&R. This is both good and bad. Creating a new language doesn't force existing communities to change; it means creating a new community and either waiting for the old ones to die off, or (ideally?) driving them into obsolescence. I remember when Wikipedia was new and there were lots of studies finding errors in their articles. Instead of replacing Wikipedia, those techniques for finding errors were simply incorporated into the editing process (as much as possible). I wish that as new classes of bugs came onto our radar, we could go back and refine old code instead of throwing it out with the bathwater. (Even OpenSSL wasn't beyond saving, judging by BoringSSL and LibreSSL. These projects still need more work, of course.)

drabiega 10y ago
Well, a lot of the point of these constraints is to reduce complexity, as the writer mentions. When you add constraints with most of those tools, you're actually adding complexity to your tooling, build process, and cognitive load if not to your actual code base.
scott_s 10y ago
And yet with those, we still have security vulnerabilities in C programs. That, I think, is a strong argument for languages which have very specific constraints. (For example: Rust.)
- NoIdeaAtAll 10y ago
  Do you have any idea how much software is run behind a firewall? If someone is even able to run my software that means they have full access to a shell and compilers for multiple programming languages. As such, there are much easier ways to run malicious code than to exploit a buffer overflow in my C or C++... So really, your argument only applies to public facing servers or web browsers. Unless you're writing one of those, I think your argument is weak.
  - MaulingMonkey 10y ago
    > So really, your argument only applies to public facing servers or web browsers. Or, you know, literally anything touching a file format that might be downloaded. PDFs, word documents, images, zip files, movies, music, sounds, icons that show up in your file explorer, user profiles, any sort of web client (email, games, chat, wget, package managers, ...) lots of poison apples out there. This kind of nonsense is why the best advice to handling USB drives you find on the ground is to toss them in a fire barrel - everyone thinks they're "behind a firewall" and that they're totally protected! They have all the protection of a wet tissue in a hurricane. Oh, but I'm just writing a terminal! I don't touch file formats! It's safe to auto-execute commands in response to pasted newlines! ...and then you've helped enable the spread of malware through clipboard hijacking Javascript. Oops. Firewalls are not a panacea. Firewalls are a roadbump. > Unless you're writing one of those, I think your argument is weak. I think your security is borderline nonexistent. I think I cannot trust you with C. I think someone is probably in your systems if you're in charge of the security side of IT, of anywhere of significance, unless you delegated enough responsibility to make you a figurehead. I mean no offense by this. A lot of reasonably talented and smart programmers make the same mistake as you, and go write a bunch of exploitable vulnerabilities in C as a result. It's not like you're one of those madmen disabling ASLR, NX, stack cookies, or some of the many other mitigation techniques being used to try and clean up after this tragedy of our times. ...right?
    - NoIdeaAtAll 10y ago
      > I think I cannot trust you with C. You really don't get it, but your arrogance is overwhelming. I don't care who you trust. > I mean no offense by this. Yes you do.
      - MaulingMonkey 10y ago
        > You really don't get it Then point out what I'm missing.
        NoIdeaAtAll 10y ago
akkartik 10y ago
"For example, C programmers don't trust anything written since K&R." That is an incredibly broad generalization. Perhaps you were implicitly assuming some qualifiers? :) --- "..that's why we have linters, static analyzers, style guides, compiler options and warnings.." But all those things are still just glorified retrofits on the job of the language. Are there any examples where a new library in a new domain adds inabilities that weren't originally enforced (or even conceived of) in the language? One example I can think of is reading/writing files. The original C had simple numbers for file descriptors, which meant that in a large application you might try to read from a write-only fd, or vice versa. The C++ standard library solved that by creating separate types for istreams and ostreams. No reason we couldn't apply that idea to C as well. On a tangent, I'm fascinated by the fact that Go hasn't bothered to steal that idea. For example, a goroutine can read or write any of the channels it has access to. If you try to juggle too many at once, that might cause the odd typo bug. It'll be interesting to see if source/sink channel types ever get retrofitted to Go in a decade or so.
- mw42 10y ago
  > It'll be interesting to see if source/sink channel types ever get retrofitted to Go in a decade or so. Channels can be designated as receive-only or send-only in variable and function declarations: ch := make(chan int, 1) var send chan<- int = ch var recv <-chan int = ch send <- 1 // ok <- recv // ok recv <- 1 // invalid operation: recv <- 1 (send to receive-only type <-chan int) <- send // invalid operation: <-send (receive from send-only type chan<- int)
  - akkartik 10y ago
    Ah! Can't believe I missed that..
andrepd 10y ago
>C programmers don't trust anything written since K&R. C is one of the most used languages in the world, and the number of programmers is surpassed perhaps only by a handful of languages. That alone tells me any generalisation you make about C programmers is most probably erroneous.
- pjmlp 10y ago
  Not everyone uses C willingly.
- nickpsecurity 10y ago
  "COBOL is one of the most used languages in the world, and the number of lines of code is surpassed perhaps only by a handful of languages. That alone tells me any generalisation you make about COBOL programmers is most probably erroneous." One a name and one phrase changed but it's still technically true. Clearly something wrong with your argument unless you think COBOL is also superior to other languages due to uptake.
  - golergka 10y ago
    Comment you're replying to didn't say anything about C being superior or not.
    - nickpsecurity 10y ago
      It implied it had good design or worth vs other languages due to massive uptake vs other languages.
      - KMag 10y ago
        My reading of the OP was just that there are tons and tons of C programmers, who almost certainly use C for many different reasons, and it's hard to believe any sweeping generalisation of such a large diverse group.... and therefore it's difficult to believe that none of the large and diverse number of C programmers trust anything after K&R.
nostrademons 10y ago
Of possible interest: http://www.nhplace.com/kent/PS/Lambda.html http://www.nhplace.com/kent/PS/Lambda.html
- akkartik 10y ago
  Seems down from here. Backup link: https://web.archive.org/web/20160304012251/http://www.nhplace.com/kent/PS/Lambda.html https://web.archive.org/web/20160304012251/http://www.nhplac...
catnaroek 10y ago
> But that's why we have linters, static analyzers, Which tend to be based on heuristics, rather than any sort of rigorous foundation. There's no shortage of static analysis tools for C and C++ that reject good code and accept bad code. > style guides, Which can be very onerous, limiting your ability to define useful abstractions, leaving you with just the bad parts of the base language (e.g., Google's C++ Style Guide). > compiler options and warnings, No amount of compiler options or warnings will force you to use an abstract type, well, abstractly, in a language that has unrestricted memory access (C and C++), unrestricted reflection (Java, .NET, anything dynamic), or both (some Common Lisp implementations). > and ultimately code reviews and good taste. If only the latter weren't in short supply...

by btrask 10y ago

drabiega 10y ago

Well, a lot of the point of these constraints is to reduce complexity, as the writer mentions. When you add constraints with most of those tools, you're actually adding complexity to your tooling, build process, and cognitive load if not to your actual code base.

scott_s 10y ago

And yet with those, we still have security vulnerabilities in C programs. That, I think, is a strong argument for languages which have very specific constraints. (For example: Rust.)

NoIdeaAtAll 10y ago
Do you have any idea how much software is run behind a firewall? If someone is even able to run my software that means they have full access to a shell and compilers for multiple programming languages. As such, there are much easier ways to run malicious code than to exploit a buffer overflow in my C or C++... So really, your argument only applies to public facing servers or web browsers. Unless you're writing one of those, I think your argument is weak.
- MaulingMonkey 10y ago
  > So really, your argument only applies to public facing servers or web browsers. Or, you know, literally anything touching a file format that might be downloaded. PDFs, word documents, images, zip files, movies, music, sounds, icons that show up in your file explorer, user profiles, any sort of web client (email, games, chat, wget, package managers, ...) lots of poison apples out there. This kind of nonsense is why the best advice to handling USB drives you find on the ground is to toss them in a fire barrel - everyone thinks they're "behind a firewall" and that they're totally protected! They have all the protection of a wet tissue in a hurricane. Oh, but I'm just writing a terminal! I don't touch file formats! It's safe to auto-execute commands in response to pasted newlines! ...and then you've helped enable the spread of malware through clipboard hijacking Javascript. Oops. Firewalls are not a panacea. Firewalls are a roadbump. > Unless you're writing one of those, I think your argument is weak. I think your security is borderline nonexistent. I think I cannot trust you with C. I think someone is probably in your systems if you're in charge of the security side of IT, of anywhere of significance, unless you delegated enough responsibility to make you a figurehead. I mean no offense by this. A lot of reasonably talented and smart programmers make the same mistake as you, and go write a bunch of exploitable vulnerabilities in C as a result. It's not like you're one of those madmen disabling ASLR, NX, stack cookies, or some of the many other mitigation techniques being used to try and clean up after this tragedy of our times. ...right?
  - NoIdeaAtAll 10y ago
    > I think I cannot trust you with C. You really don't get it, but your arrogance is overwhelming. I don't care who you trust. > I mean no offense by this. Yes you do.
    - MaulingMonkey 10y ago
      > You really don't get it Then point out what I'm missing.
      - NoIdeaAtAll 10y ago

akkartik 10y ago

"For example, C programmers don't trust anything written since K&R." That is an incredibly broad generalization. Perhaps you were implicitly assuming some qualifiers? :) --- "..that's why we have linters, static analyzers, style guides, compiler options and warnings.." But all those things are still just glorified retrofits on the job of the language. Are there any examples where a new library in a new domain adds inabilities that weren't originally enforced (or even conceived of) in the language? One example I can think of is reading/writing files. The original C had simple numbers for file descriptors, which meant that in a large application you might try to read from a write-only fd, or vice versa. The C++ standard library solved that by creating separate types for istreams and ostreams. No reason we couldn't apply that idea to C as well. On a tangent, I'm fascinated by the fact that Go hasn't bothered to steal that idea. For example, a goroutine can read or write any of the channels it has access to. If you try to juggle too many at once, that might cause the odd typo bug. It'll be interesting to see if source/sink channel types ever get retrofitted to Go in a decade or so.

mw42 10y ago
> It'll be interesting to see if source/sink channel types ever get retrofitted to Go in a decade or so. Channels can be designated as receive-only or send-only in variable and function declarations: ch := make(chan int, 1) var send chan<- int = ch var recv <-chan int = ch send <- 1 // ok <- recv // ok recv <- 1 // invalid operation: recv <- 1 (send to receive-only type <-chan int) <- send // invalid operation: <-send (receive from send-only type chan<- int)
- akkartik 10y ago
  Ah! Can't believe I missed that..

andrepd 10y ago

>C programmers don't trust anything written since K&R. C is one of the most used languages in the world, and the number of programmers is surpassed perhaps only by a handful of languages. That alone tells me any generalisation you make about C programmers is most probably erroneous.

pjmlp 10y ago
Not everyone uses C willingly.
nickpsecurity 10y ago
"COBOL is one of the most used languages in the world, and the number of lines of code is surpassed perhaps only by a handful of languages. That alone tells me any generalisation you make about COBOL programmers is most probably erroneous." One a name and one phrase changed but it's still technically true. Clearly something wrong with your argument unless you think COBOL is also superior to other languages due to uptake.
- golergka 10y ago
  Comment you're replying to didn't say anything about C being superior or not.
  - nickpsecurity 10y ago
    It implied it had good design or worth vs other languages due to massive uptake vs other languages.
    - KMag 10y ago
      My reading of the OP was just that there are tons and tons of C programmers, who almost certainly use C for many different reasons, and it's hard to believe any sweeping generalisation of such a large diverse group.... and therefore it's difficult to believe that none of the large and diverse number of C programmers trust anything after K&R.

nostrademons 10y ago

Of possible interest: http://www.nhplace.com/kent/PS/Lambda.html http://www.nhplace.com/kent/PS/Lambda.html

akkartik 10y ago
Seems down from here. Backup link: https://web.archive.org/web/20160304012251/http://www.nhplace.com/kent/PS/Lambda.html https://web.archive.org/web/20160304012251/http://www.nhplac...

catnaroek 10y ago

> But that's why we have linters, static analyzers, Which tend to be based on heuristics, rather than any sort of rigorous foundation. There's no shortage of static analysis tools for C and C++ that reject good code and accept bad code. > style guides, Which can be very onerous, limiting your ability to define useful abstractions, leaving you with just the bad parts of the base language (e.g., Google's C++ Style Guide). > compiler options and warnings, No amount of compiler options or warnings will force you to use an abstract type, well, abstractly, in a language that has unrestricted memory access (C and C++), unrestricted reflection (Java, .NET, anything dynamic), or both (some Common Lisp implementations). > and ultimately code reviews and good taste. If only the latter weren't in short supply...