
That Pretty Much Wraps it Up for C - DaNmarner
http://inessential.com/2014/04/11/does_that_pretty_much_wrap_it_up_for_c_
======
JoshTriplett
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.

------
zabcik
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.

~~~
azth
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.

~~~
lettergram
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.

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

~~~
fluidcruft
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.

------
georgemcbay
... 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.

------
monochr
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.

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

------
chubot
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...](http://scholar.google.com/scholar?cluster=9814570315440570792&hl=en&as_sdt=0,5&sciodt=0,5)

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/](http://www.cl.cam.ac.uk/research/security/capsicum/)
. This works with existing code.

------
CSDude
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.

~~~
prospero
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.

~~~
jibsen
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](http://article.gmane.org/gmane.os.openbsd.misc/211963)

------
joveian
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/](http://www.ats-lang.org/)

~~~
EGreg
What about Go?

~~~
georgemcbay
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).

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

[http://queue.acm.org/detail.cfm?id=2010365](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...](http://www.slate.com/articles/technology/bitwise/2014/02/apple_security_bug_a_critical_flaw_was_extraordinarily_simple.html)

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.drpaulcarter.com/cs/common-c-errors.php)
[http://www.andromeda.com/people/ddyer/topten.html](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.

~~~
ArkyBeagle
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."

~~~
mamcx
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.

~~~
ArkyBeagle
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.

------
no_l0gic
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...](http://www.tedunangst.com/flak/post/analysis-of-openssl-freelist-
reuse)

Who can resist Theo:
[http://article.gmane.org/gmane.os.openbsd.misc/211963](http://article.gmane.org/gmane.os.openbsd.misc/211963)

~~~
mamcx
"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.

------
azth
> 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.

~~~
ArkyBeagle
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.

------
EGreg
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.

------
tvieira79
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.

------
revelation
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.

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

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

------
abimaelmartell
I think bad programmers should be retired, not the language

------
nickalto
Gotta love brent.

