

What's your C migration plan? - lucasr
http://wingolog.org/archives/2011/10/13/whats-your-c-migration-plan

======
jrockway
You know what I've learned over the years? While many people are very bad
about writing C, I'm pretty good at it. So C is not a bad language; there are
just a lot of bad programmers around using it.

(And if you're wondering how to write good C? Make object ownership explicit.
Never have malloc and free more than a page of code apart. Don't expose data
structures as API. Make errors put your routine into a defined state that the
caller can understand. Use bstrings instead of cstrings.

And although I don't write much C++, the more I learn about it, the more I
believe it's possible to write good C++. Most people won't spend the time to
write good software, and when you do that in C or C++ it's an absolute
disaster. But if you go slowly, plan, think, exercise care, and review your
work regularly, you can get good code that runs fast.

You can write a safe Haskell application in 10x less time than you can write a
safe C++ application, though.)

~~~
bmastenbrook
Hail, god amongst men. Once upon a time I thought I was a very good C
programmer. Today I know myself to be a terrible programmer. I surround myself
with safety mechanisms such as -Wall -Wextra -Werror and the clang analyzer,
but even these tools cannot stop me from shooting myself in the foot time and
time again. Please enlighten me, such that I may learn to write safe code in
an unsafe language infallibly.

~~~
to3m
Each time you put a bug in, make sure to take it out afterwards. Nobody cares
how many bugs you put in, only how many are left :)

~~~
bmastenbrook
Oh! It's so easy. I can't believe I didn't think to do that before.

... but every time I do find a bug, I am surprised to find it. Thus it stands
to reason there are bugs I have not yet found. How do I find all of them?

~~~
jrockway
Care. I recommend "Programming Pearls" as a good introduction to this concept.

~~~
tptacek
How careful are you with your code? What would you be willing to stake on that
answer?

~~~
jrockway
I'm not saying I care about my code. I'm just saying that one can write bug-
free code if one takes the time to do it.

~~~
tptacek
Do you have a piece of code you feel confident about, such that you'd be able
to say "here is an existence proof of carefully-written resilient C code of
some significant length"? I'd like to take you up on an offer to validate that
proof.

~~~
jrockway
I do, but it's unfortunately internal at work. Everything I write for fun has
so many library dependencies that you just have to cross your fingers and hope
that it will all work as documented :)

------
coliveira
This is just nonsense. C is perfect for what it is supposed to do: systems
programming, the kind of software you write when creating operating systems,
debuggers, and device drivers. It will hardly ever stop being useful for these
tasks.

People that make this kind of complaint were using C for the wrong type of
software. If you want to write a web application in C you just need to
reevaluate your tool set.

~~~
ajross
Exactly. It's sad that in the modern world there are people (smart, productive
people even) who are so far removed from system stuff that they just plain
forget that this software still needs to be written.

Now, is C the best possible tool for these jobs? Certainly not. But it's the
one we have and it's got a pretty fantastic track record.

~~~
tptacek
As regards quality and reliability in _consumer software_ , C has a godawful
track record.

The heart valve code inherits constraints that make C a lot safer: it has an
extraordinarily limited feature set, its functional interfaces are simple, it
changes rarely, and the time - to - market pressures it faces are dwarfed by
other factors like certification and manufacturing.

Consumer software is richly functional, has complex interfaces, changes
_constantly_ , and is written under ridiculous scheduling pressure. In that
environment, C does indeed give you software that is as likely to enable
someone to install a trojan on your system as it is to properly render an
image.

~~~
mtoddh
Kind of ironic considering how much security industry related software is
written in C/C++ (snort, dragon, bro, nessus, nmap, ...)

~~~
tptacek
You want to have a conversation about the code quality of a typical C-code
security tool? :)

------
bitops
I doubt that the tech industry will ever move completely away from C. (I had a
friend who was doing graduate work in physics and he was required to do all
his work in Fortran, believe it or not, so old languages do stick around).

For "mainstream" (read: enterprise) software, yes, C may fall out of favor,
but it's a great language and here to stay.

There are just too many cases where C is the right tool for the right job and
it would be silly to use a different language.

I'm thinking particularly of embedded software. While languages like Lua are
great for embedded scripting, they still need something to script against.

So, C isn't going anywhere and I expect that 100 years from now it will still
be a worthwhile language to program in.

(Also, C is very much the Latin of modern programming. Learning it helps your
understanding of so many other things. In case you're curious, Lisp is Greek
and I mean that affectionately).

~~~
tptacek
You think in 100 years we'll be writing in a language whose only real data
type is an integer, overloaded to represent human language, memory addresses,
and (by extension) the identities of functions?

What a depressing thought.

I love writing C code (the model of programming where virtually anything is
possible by modifying and reinterpreting integers is often a fun one), and
it's my best language, but I hope we grow out of it sooner than later.

~~~
statictype
As long as we're running our software on a Von Neumann machine, there will be
a need for a language which is just a thin layer on top of it. Considering we
already have one, it seems hard to believe that it will go away without a
fundamental change in how computers work. (Which is not to say we won't have
better languages - just that we will always have the bare-metal one as well)

------
hkarthik
C is the best thing we have that's truly cross platform and has consistent
performance everywhere without any company to claim ownership of it.

Until that changes, C is here to stay.

------
tptacek
The nice thing about an article like this is that anyone who is receptive to
it truly shouldn't be writing C code, and anyone who should be writing C code
is (in almost all likelihood) not receptive to it.

------
forrestthewoods
As a game developer this post is rather amusing. I have far more questions
about what happens behind the scenes on the python line than the C line.

------
__david__
It really depends on what you are writing. If you're trying to write the next
great startup web app then, yeah, use python or ruby or perl--C is probably
too finicky for the fast pace of a web startup. But if you're writing systemd
(an "init" replacement) you'd be the object of ridicule if you wrote it in any
of those languages.

------
sbov
I've been recently using Python more rather than Java, and I find myself
writing C more than ever. I always seem to find some speed/memory issue in my
programs that when rewritten in C goes away. Maybe I'm just not proficient
enough in Python to avoid them yet. I would say its still a net gain over raw
C.

~~~
swah
Is it that easy to write in C and call from Python that you don't think twice
about it?

~~~
Kliment
Yes, it actually is. Writing Python extensions in C was always easy, but now
there's ctypes, and you don't even need to do that anymore. You can just call
a shared library function directly from Python.

------
trbecker
What this can possibly mean? Because C is everywhere. It is in the code that
runs the VM of your favorite language. It is in most compilers. It provides
basic system services. Why should we have a plan to migrate from something
that is everywhere?

------
swah
But I don't want to use his language, I want to hack on it with him. To see
how he solves problems. So, C.

Unless its something like Factor, where most of the implementation is written
in Factor.

------
blackhole
Changing languages will not save you from security holes, only change the kind
of mistakes you have to worry about. Only knowing how to write secure code can
save you from security holes. You cannot ignore how computers work, no matter
how many layers of abstraction and libraries you pile on in an effort to
shield yourself from reality.

~~~
tptacek
Changing languages will absolutely save you from classes of security holes.
Java programmers do not have to keep a working model of object memory
lifecycles in their head to build safe programs. C programmers, on the other
hand, still do have to care about the metacharacters of the HTML DOM and SQL.
In fact, because it's a bitch to rewrite retained char* strings in place
without pegging malloc() to the top of your gprof profile, C programs are
actually slightly _more_ prone to the kinds of security holes you're implying
plague languages like Java.

Even if you stretch to find a class of flaw that only affects a language like
Perl (for instance, the ease with which Perl allows you to write code where
metacharacters will allow an attacker to stuff commands into a shell), you
simply have to go back 10 years or so to see the 8lgm posts that did the same
thing to C programs all over the Internet.

~~~
blackhole
And yet, this still ignores the rather amusing fact that the more libraries
and VMs and whatnot in between you and the computer hardware, the more chances
your program will suffer a security hole because of a mistake in one of those
libraries. Not too long ago someone found a bug in PHP that would cause it to
go into an infinite loop if you put in a wrong number. These kinds of things
happen, so if your going to write secure code, the only thing that will save
you is being really good at writing secure code on whatever platform you are
choosing to write code for. The only thing that changes is the types of
security holes you have to worry about. Instead of buffer overflows, you have
to know that function x does x and in some cases function y is more secure but
only if there's a solar eclipse, etc. The higher level language you use, the
more complexity the system has, which increases the possible security flaws
even as the languages reduces other security flaws. The end result is simply
that any given language will move the problem around, not actually solve it.

~~~
tptacek
The bug you're talking about is a result of C code. I'm not sure what point
you're hoping to make by observing that the C code underpinning high level
languages is prone to vulnerabilities; I feel like that point is rather more
supportive of _my_ argument.

------
klochner
It's fitting that his site is timing out.

------
zmanji
I am unable to load the article. Is there a mirror?

~~~
mappu
Google Cache seems to have it.

[http://webcache.googleusercontent.com/search?q=cache%3Ahttp%...](http://webcache.googleusercontent.com/search?q=cache%3Ahttp%3A%2F%2Fwingolog.org%2Farchives%2F2011%2F10%2F13%2Fwhats-
your-c-migration-plan)

Plain text copy: <http://c-migration-plan.pen.io>

------
user911302966
My suspicion is that this is not a C programmer at all. Claiming that you've
"written loads of it" certainly lends the author a cloak of credibility, but I
don't buy it.

"This one, you really can't tell."

A competent C programmer can absolutely discern what is happening... more
importantly, though, is that the two examples don't do the same thing.

I stopped reading at that point.

~~~
tptacek
Upon hitting his website, you were one single click away (the "software" link,
next to "about") from learning that he's the co-maintainer of Guile, a C
implementation of Scheme.

------
mansr
The author of that (badly timed, btw) post probably does not know that Python
is implemented in C.

~~~
tptacek
The author of that post is a C programmer. This isn't just snark; it's dumb
snark.

~~~
mansr
A C programmer posting that kind of nonsense is even more stupid than a non-C
programmer doing it.

