8 ms·
I'd actually blame it on idiots writing C myself. You can't really have a totally safe systems programming language (correct me if I'm wrong here).
by hp50g 14y ago
I'd actually blame it on idiots writing C myself.
You can't really have a totally safe systems programming language (correct me if I'm wrong here).
- b6 14y ago> idiots This is a million times wrong. It's not about humans being smart or stupid, it's about humans being bad at being careful millions and millions of times without error. The answer isn't to tell them to be more careful. They can be more careful, but they are human, so they will still make mistakes. The answer is for them to use higher level languages that eliminate whole classes of errors.
- S4M 14y agoI think the GP is calling them "idiots" not because they use C in a dumb way, but because they keep using a language that is error-prone.
- mikeash 14y ago"You can't really have a totally safe systems programming language (correct me if I'm wrong here)." He doesn't seem to think that others would be better.
- jdboyd 14y agoA type system that isn't 100% safe can still be a massive improvement over C or even C++.
- hp50g 14y agoYou are wrong: I'm calling them idiots because they use C in a dumb way and don't stick it through valgrind etc.
- coldtea 14y ago>I'd actually blame it on idiots writing C myself. Couldn't be more wrong though. The people that wrote UNIX and its whole C userland were far from idiots -- more like geniuses. People like K&R, Bill Joy, etc (and until the 90s they weren't even that many, mainly people from elite computing schools and research centers). It's not like some moron high school dropout, "Learn C in 24 hours"-reading people wrote UNIX and the common server stuff we use (Bind, Sendmail, etc).
- miloshadzic 14y agoI like that Unix, Smalltalk and Lisp have a similar idea of smaller things getting composed. They are all different but I wouldn't judge the ideas based on what we have today.
- hp50g 14y agoAgree here. My statement perhaps could be better written. I'm saying not that idiots write C, but idiots can write C badly and often do. Much as anyone can cross a road, idiots can do it and reliably get squashed every time. I disagree about sendmail though - that was a stinking turd and I have been ever grateful since postfix arrived on the scene :)
- pjmlp 14y agoProblem is the majority of developers in the world are not elite, thus the security pain we have to endure nowadays.
- alberich 14y agoTotally safe I doubt there is. It seems there are safer languages (and OS designs). However, there are pratical considerations (e.g performance impact and stuff like that) which make such approaches unattractive for production use.
- pjmlp 14y agoThis is more FUD than anything else. Languages like Ada and Modula-2, just to cite two examples from many, allow for safer coding while having similar performance. The people that cite the performance impact of bound checking and other features, usually tend to ignore that they can be disabled if required for performance reasons, because it suits their arguments that no other language can achieve C like performance. Or they like to forget that the industry has invested more in optimizing compilers for C than for other languages. So they end up discussing languages without regard for the implementations.
- deleted 14y ago[deleted]
- alberich 14y agoI was referring to operating systems architectures, not only programming languages. While I believe you could write an operating system in Haskell, for instance, I don't know nothing about it's performance. However, microkernels, even though are safer, have some performance drawbacks.
- pjmlp 14y agoAnd yet, one of the best real time operating systems (QNX) is micro-kernel based.
- yoklov 14y agoYou can't really have a totally safe systems programming language (correct me if I'm wrong here). It depends what you mean by totally safe, but Cyclone (http://cyclone.thelanguage.org/ http://cyclone.thelanguage.org/) is a type and memory safe dialect of C. It works by adding additional information to the type of every pointer, e.g. if it can be NULL, if it's NUL terminated, if you know the length, the scope it was allocated in, the location on the stack it's from, etc... This all happens at compile time, and it runs about the same speed as C, so I think it qualifies. From what I've read, this has had more of an influence on programming language designers/implementers (rust, possibly c++11, probably more), than on anybody else, though. edit: NULL -> NUL
- hp50g 14y agoThis sort of stuff works until you need to poke some registers in a graphics card or the language's MM has a bug or you need C's dynamic nature.
- martinced 14y ago"You can't really have a totally safe systems programming language (correct me if I'm wrong here)." It bears repeating because most people are totally unaware of this but you can use code verifiers to analyze C code and then prove that that C code is free from buffer overflow/overrun, unexpected pointer dereferencing, etc. Now the bad news: on the tiny codebase of 7000 lines of code of the esL4 microkernel such a prover found hundreds of potentially exploitable errors. They've all been fixed and it is now guaranteed that that codebase cannot be exploited due to, say, a buffer overflow/overrun/underflow in that microkernel. It doesn't mean there aren't other way to exploit that OS: but simply it is a fact that there isn't going any exploit using a buffer overrun in that part of the codebase. That's already quite a big win. This is fascinating stuff and I'm sure we'll see more of that in the future.
- betterunix 14y agoSure, but there are two major classes of bugs we need to worry about these days: * "Mechanical" issues like dangling pointers, buffer overflows, integer overflows, etc. * Design errors Unfortunately, C makes the first class exceedingly easy to create, and makes the second class exceedingly hard to prevent.
- hp50g 14y agoC also makes memory access and device driver code very easy. The mechanical issues are a side effect of that. As for design errors, they are hard to prevent anywhere.
- betterunix 14y ago"C also makes memory access and device driver code very easy. The mechanical issues are a side effect of that." I have two problems with this reasoning. First, C is being used for more than writing device drivers; most programs written in C are not device drivers. Second, and more important, is that low-level memory access and the sort of bit-twiddling you are talking about can be done in Common Lisp, and I doubt that you would be shocked to know that the operating systems written in Lisp for Lisp Machines had device drivers. It is possible for any high-level language to expose a low-level pointer type, and doing so will not force programmers to use such low-level constructs in higher-level code. "As for design errors, they are hard to prevent anywhere." While true, they are much harder to prevent in C because of the complicated semantics, the enormous amount of undefined behavior, and the plethora of edge cases one must account for. When something as simple as incrementing a counter forces you to deal with edge cases and potentially undefined behavior, it is pretty hard to verify that a C program actually implements a design, even when that design was formally specified and checked. The lack of high-level features and constructs worsens this situation by inflating the number of lines of code in an implementation.
- pjmlp 14y ago> C also makes memory access and device driver code very easy. Like any systems programming language, nothing special about C.