That Pretty Much Wraps it Up for C | Hacker News Reader

That Pretty Much Wraps it Up for C

inessential.com

52 pointsDaNmarner32 comments

There's a small set of systems code for which C is a requirement, for various reasons. (There are experimental systems trying to get non-C languages into those areas too, and more power to them.)

But today, writing large piles of new C code interacting with untrusted users and data is both painful and irresponsible. Pick a higher-level language, any higher-level language.

As far as I can tell, the main thing keeping C in its entrenched position these days isn't performance, or preference; it's C's status as the language of the native platform, that every other decently powerful language can talk to via FFI. If you write a new library in language $FOO, it'll mostly get used by other code in $FOO; if you write a new library in C, many different languages can use it.

However, adhering to the C ABI does not require writing code in C. And if enough new libraries start providing a C interface backed by a more powerful language, perhaps we can start establishing careful extensions to the C ABI to better fit higher-level languages (such as standard ways to pass buffers).

That's not to say there aren't new classes of systemic bugs in other languages, too. And FFI code, by necessity, lets you write C-like bugs. However, there's no excuse for buffer overflows and integer overflows anymore when any decent high-level language has buffer types and bignums.

This is inflammatory and vapid. OpenSSL just needs better code review and should follow the standards they are programming to. It's not the death knell for an entire programming language.

True, though hopefully it will make people thing that, no matter how smart the programmers working on a project of a similar caliber are, there will be, for the most part, vulnerabilities like this caused by using C.

vulnerabilities were not caused by using C, they were caused by human error. C may be harder to read, but it is way faster than most of the alternatives.

That particular human error would have been impossible if using another popular language (other than perhaps C++).

Perhaps you missed the part of the drama where it was revealed years ago that OpenSSL prefers to roll it's own malloc rather than work out issues in their code that were exposed when porting to other platforms? OpenSSL would just have rolled their own shit to circumvent whatever protections you think other languages provide.

It's the attitude that was wrong, not the language. Stupid always finds a way. Back in the day, porting to different compilers and platforms was one way to find and quash bugs. Nowadays I guess you can just pitch a single OSS compiler and rely on it's implementation details and bugs. Drag your own chunks of libc around and presto, no porting headaches. That's such a stupid attitude.

... not until something else with a sane, stable ABI that everyone agrees upon comes along (and before anyone points it out, I realize C has no actual standard defined ABI, but it doesn't matter in practice because following the OS/arch ABI is always the path of least resistance when linking C).

For all of its issues, C is still incredibly important for being the only language you can fairly easily integrate with virtually any other language.

That Pretty Much Wraps it Up for hammers I love hammers. So damn much. I enjoy using heavy hammers.

I love having some nails and some wood and the flexibility to do whatever I want. I love that it imposes a discipline that prevents me from using that flexibility in stupid ways.

But between hitting your finger and bent nails I have to wonder if my beloved tool should be retired — at least for everything that could be a carpentry issue. (Which is potentially everything, I suppose.)

There are two things that make other tools better for these things: 1) in many tools these particular bugs are impossible, and 2) there are often better tools that can prevent those particular flaws from happening in a chunk of wood.

The finger hitting bug is a major hassle. What worries me is that the next time something else might happen — maybe someone hits their toe or breaks their hand. (Or worse.)

If we’re serious about protecting ourselves from pain and other malevolent entities, maybe we have to move away from hammers.

(I suggest this with great reluctance. And a realization that the cost of this would be huge.)

In short, this is click bait and stupid. C is a tool, it's up to the people using it to make sure the tool is used right. What we need is something closer to build codes for software. Right now it looks like some people think that building sky scrapers out of marshmallows is a wonderful idea and anyone pointing out that this is a bad idea is called a Luddite.

More like someone missing the nail and nuclear explosions happen in another part of the world.

The issue is more software architecture than programming languages. DJB writes plenty of C, and manages to create secure systems.

If you follow the principle of least privilege and separate things into processes, then you can write secure systems in C. Granted, there is friction with this approach on modern Unix, but it's more than worth it, and much more likely to get done than rewriting all of OpenSSL or OpenSSH or nginx or Python in Rust or whatever.

See "Some thoughts on security after 10 years of qmail 1.0":

http://scholar.google.com/scholar?cluster=981457031544057079...

People can and do write insecure code in any language. The most popular ones seem to be the most insecure -- C, PHP, and JavaScript -- and that doesn't seem to be coincidence (liberal languages have advantages as well as diadvantages).

Systems have to be designed so that tiny mistakes aren't catastrophic, and rewriting everything in a different programming language is probably the most costly way of achieving that goal. In other words, it's an economic impossibility.

See also: http://www.cl.cam.ac.uk/research/security/capsicum/ . This works with existing code.

Please, it can happen in any language, it depends on how you write it. If you do not sanitize your inputs you get sql-injected, and is this fault of SQL or you? I agree it is harder to write C code safely, but this was a stupid bug, not actually a C incompetence. You could allocate a large buffer in Java, and you could use `System.arraycopy(array, 0, part, 0, size);` instead of OpenSSL: `memcpy(bp, pl, payload);` both lacks only a boundary check and language provided checks will not help you in Java. Java is given as an example language that provides boundary checks. It applies to others as well.

Sure, but that's bounded by the size of the buffer in Java. A bad boundary to the arraycopy in Java will throw an exception, not give you the contents of memory beside the buffer. These are not comparable failures.

As I understood it, part of the problem was that they rolled their own memory handling which cached allocations [1].

Otherwise, I imagine system memory protection would have found this much sooner.

[1]: http://article.gmane.org/gmane.os.openbsd.misc/211963

The problem is that no other language has captured the good points of C anywhere near as good as C. There are ways of using C that are much less likely to result in this type of bug - and the more complex processing that other popular languages can add in surprising places can cause bugs too. I've been meaning to learn ATS that basically adds a separate validation layer to C: http://www.ats-lang.org/

What about Go?

I love Go, but it is a prime example of a language that fails on the problem C solves that nothing else does that I mentioned in another post on this thread...

Getting Go to link to anything but C (and C++, but only if it uses C interfaces) is (depending upon the specifics of the other language) difficult to nearly impossible (and at some point certainly involves using C anyway).

While it has its good points, Go lacks the performance and memory footprint of C programs in constrained environments, or at the system level.

For people that think that "C is not the problem":

http://queue.acm.org/detail.cfm?id=2010365

This is C thing, that have a lot of problems. In pascal, no problem.

And the worst?

IS STILL A PROBLEM. Decades after.

And this is only one thing.

The other bug: http://www.slate.com/articles/technology/bitwise/2014/02/app...

Is a C problem. No just the goto. YEARS AFTER, still here. IS the "brace" thing. Is not mandatory.

C have a lot of stupidity built-in (ie: Bad by default):

http://www.drpaulcarter.com/cs/common-c-errors.php http://www.andromeda.com/people/ddyer/topten.html

Some of this are not corner cases, and could be say are unnecessary to fight them decades after. You know, if B turn to C, why not turn to something better? Instead, the inertia (like happend with javascript) is push and push doing things the hard/dumb way because, well, all that people that have worked better from DECADES, they are wrong.

You either have an epistemology about defects and practices to prevent them to the best of your flawed ability or you don't. If you don't like 'C' then don't use 'C'.

You really, really need an epistemolgy. I mean absolutely no disrespect, but railing about choice of language ( although I love the links you provided; heads on pikes outside the city wall ) falls flat.

There are entire quadrants of computing for which 'C' is a grindingly horrible choice. OpenSSL for one is not one of them.

For path dependent and beyond-our-control reasons, 'C' is just about the only choice for that.

'C' programs should be invisible and close to the wire. Examples like these should give us courage in the face of pressure to let go of something too early, while that still small voice is nagging you "It's not really done."

Have good practices is good. Part of it, is not use a tool that could blow up your whole leg and drag a massive multi-million dollar pandemonium to the whole world (hyperbole Off).

Look, is clear that C, as a concept or tool, is a necessary thing. Close to the metal and all that, great. But consider this exactly like the same OpenSSL bugs: it have a problem, is patched, never again.

C don't have that. Have not improve in safety or remove any bad behavior in a decent way. Not deprecate things, not nothing.

Just " 'C' is just about the only choice for that.". That is bad!. So imagine if our only choice for hosting is Win3.11, and it continue towards Win90 and DON'T fix some very dangerous and stupid things.

This is what my rant is about.

For contrast (no just talking about pascal, ada and others -also old- saner, safer, can be close to the metal, languages), see what have happened with Obj-C.

It start horrible, but slowly is moving to something more ok. Now, I don't have problems because a bad release, the language remove that pain. The syntax is improving, slowly, but improving. The compilers are moving to something better.

That is what I'm talking about.

I am quite sympathetic. We oldsters actually expected Modula-2, Obj-C or Ada to take off in the '80s. That didn't happen. The "reentry curve" for them was too steep and they burned up. 'C' didn't. It's the canonical "worse is better."

Turbo Pascal had good market share, but was eclipsed by 'C'. We really did have to squeeze every cycle back then; 'C' was better because you didn't have to do as much raw assembly. The cast of companies was largely established before even Windows; you were more or less encouraged to write TSRs. 40 miles uphill in the snow both ways to school! :)

I expect that the sheer mass of 'C' code out there creates quite a problem for wholesale replacement. So many computer things have been swept away; I doubt Linux is going anywhere. One suspects that the "cockroach" nature of 'C' is why it's still here...

Oberon is still out there; but perhaps the better thing is to simply increase the resources of the OpenSSL community.

This has nothing to do with the language and everything to do with the programmers and practices - some great write-ups:

http://www.tedunangst.com/flak/post/analysis-of-openssl-free...

Who can resist Theo: http://article.gmane.org/gmane.os.openbsd.misc/211963

"Nothing to do with the language"?

Seriously, apart from C, what other language cause almost any of their users to think: I must do my own malloc, or String type, or XXXX.

This kind of weird is typical of C.

> I love that it imposes a discipline that prevents me from using that flexibility in stupid ways.

What discipline? Am I missing something?

> maybe we have to move away from C.

Hopefully, Rust will facilitate this transfer.

The discipline, as he said, to Not Be Stupid. There's still a floor on the error rate, but it's entirely possible to use these tools responsibly.

I will believe Rust when I see it. We may, however, look at Lua. That might not sell, though. Lua is amazing but I'm not sure a culture is ready to bifurcate its code base like that.

Given the complexity of all this, it's amazing we don't get a Heartbleed sized thing per week. The color and shape of this reminds me of when markets take a tumble because of a cascading failure - some poor schmoe ends up with a margin call and everybody sweats a lot for a while.

At work, I do this: "Are you done?" "Yeah, but I don't trust it yet." They're really nice about this.

Overreaction. With enough eyes all bugs are shallow. Look at Linux and BSD vs BeOS or something.

If you want safe operations in C, just write a few simple functions and use those.

Just because of bad programming practices you are diminishing the language. If I'm allowed to make an analogy to what you said, it is the same as cutting a tree because we found a rotten fruit. I agree with the @CSDude arg, every language has its weaknesses and a good developer should recognize and understand that.

Oh come on. People that know of the pitfalls build useful abstractions that keep someone falling in from burning down the house. Look to the Linux kernel for evidence of C being used by responsible people, not morons that can't rise above hacking on raw memory straight out the socket.

Not a lot of content in this post. Not to mention that either everything in it has either been said before, or completely exaggerated.

Or we could have better code review and donate to OpenSSL so they have more motivation.

I think bad programmers should be retired, not the language

Gotta love brent.

Reply on news.ycombinator.com