Ugh... these kinds of extreme posts really piss me off. Yes, C is unsafe. Yes, there are safer higher level languages, but there's a reason C is used. Because it's REALLY freaking fast, and allows you to actually tune how memory is used.
The issue with C is not the language itself. It's the complexity of the project. Once a project reaches a certain size, no programmer will be able to keep the entire thing in their head at one time. That's why the bugs appear.
I have no issue with saying that C is hard to work with in giant projects. If you have an issue with that, write the sections of code that bottleneck in C, and then glue them together with a higher level language (I personally like Lua for this).
Also, the post is mainly complaining about security issues for Chrome. Assuming Chrome is rewritten in Rust or Go, will these security issues vanish? Of course not. Bugs (especially security bugs) will exist in all software, whether it's written in C or Ruby.
So the results of rewriting all C code in the world is: slower, less optimized code and continued existence of security bugs. Sounds great.
> Assuming Chrome is rewritten in Rust or Go, will these security
> issues vanish? Of course not
It's true that they will never _vanish_, but all of the ones related to memory safety, which are the ones the article focuses on, shouldn't happen in Rust:
> 70% of the high-risk bugs in Chrome 44 would have been prevented
> if Chrome were written in a memory-safe language instead of C/C++.
(it's true that it's not 100%, because someone could still write bad code in an unsafe block, but that's a _significant_ reduction in the surface area, which should lead to a similar reduction in errors.)
> Make is fairly easy to learn, at least in its basic form. Autoconf is horrendous.
I completely agree. Make is extremely flexible on it's own. I don't understand the need to abstract the build system to generate thousand-line makefiles that are impossible to hand edit.
As benwaffle says in adjacent comment, make is the 80% solution that works most of the time. Autoconf is the 100% solution that's supposed to work everywhere, no matter how weird or long-dead your UNIX is. In order to do that it does a vast number of compatibility tests. The result is complex enough that simple substitution of makefiles doesn't quite cut it.
Of course, that imposes the cost of 100% compatibility on every developer, when most would be happy to just build on today's Linux and call it a day.
> Autoconf is the 100% solution that's supposed to work everywhere
> Of course, that imposes the cost of 100% compatibility on every developer, when most would be happy to just build on today's Linux and call it a day.
The reality is that when you use programs built with autotools on systems that aren't mainstream, you'll have troubles. Because the scripts aren't right and were only tested by Linux developers on Linux.
And much of the time, I find it faster and easier to fix a broken makefile than to fix broken autohell.
> And much of the time, I find it faster and easier to fix a broken makefile than to fix broken autohell.
Exactly. 99% of the time, a broken makefile simply has an incorrect linker path or cflag. When it's not a path, the Makefile is structured in a way that makes sense and is easy to fix. If an autoconf project is broken, I just scrap it and don't even bother trying to build it.
The other issue with autoconf is that it's not standardized. So many of the autoconf projects I've seen have shell scripts (to install it or download deps) mixed in that only add more confusion. Some of them have a configure script. Some have a configure.in, so you have to generate the configure yourself.
100% of the makefiles I've seen have a build, install and clean task. Sure, it's not required, but everybody does it. You can't say the same for autoconf.
The idea is to make it work on all platforms, only requiring minimal POSIX compatibility. It also checks for any requirements you specify, and sets up stuff like make install, make dist-check, make check. It handles compiling your code into a library regardless of the os
Frankly, I don't use a lot of crazy libs or IDEs when writing C code. Most of my projects consist of one or two external libs and a few simple makefiles. I use Vim and clang/gcc for compiling and lldb/gdb for debugging.
As for compiler flags, the only ones I ever worry about are `-O`, `-g`, `-c`, CFLAGS and LDFLAGS.
What I've learned is that the way C includes other files/libs is extremely simple. The header files are simply a simple mapping of the code in the `.so` or `.a`. If it's a n `.so`, you can't make it a static executable and if it's `.a` you have to.
I've never worked directly with low-level microcontroller programming, and the extent of my electronics knowledge is some fiddling with arduino. When I did that I used ino (http://inotool.org/) to compile and upload code to the board.
EDIT:
Projects that have good C code include: http://suckless.org/ and the linux kernel (and other stuff by Linus Torvalds). Avoid anything with GNU (most of it's over-engineered)
The issue with undefined behavior is it's kind of hard to... well... define. It's an odd combination of unsafe memory, float/integer rollover, and rules with memory allocation. I wasn't quite sure how to clearly state it.
All you really need to say is: There are some rules in C which neither the compiler nor the runtime is required to check if you've broken. On the contrary, the implementation is allowed to assume that you haven't broken them - which means that if you do break these rules, all bets are off as far as the behaviour of your program goes, which may lead to all sorts of strange and apparently inconsistent results.
Yeah I tend not to get hung up on the different ways it can trigger. It's more like, if you trigger it your program might run fine for now and then suddenly act up one day. It might die before the undefined behavior. It might launch nukes. Still sure you want to get into this? No? Want to go back to Ruby? Well, Ruby is built atop C. That's the five states of grief I try to get them through.
Red Hat's Richard Jones (who is also often commenting on Hacker News) does a lot of system programming in OCaml (mostly VM management-related I think):
Hey author of the slides here, glad you liked it :D
I used http://remarkjs.com/ to make the slides. All you have to do is include the script, add a textfield with your content in markdown and it automatically converts to a slide show.
