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

[jrockway]

The only effective safety mechanism for C code is size. You must treat everything you write in C as though it's a tiny standalone library, and then build your application from those libraries. "Frameworks" do not work here. (Unless, that is, you're going to go insane and implement a refcounting gc and double-indirection pointers, like C++ programmers do. That works, but at that point, you've lost all speed and simplicity benefits and you might as well just use your favorite Java substitute instead. Remember: you write C because you want other stuff to use it. When you implement your own memory model and semantics, you lose that. And then you have if statements, integers, goto, and segfaults.)

[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?

[to3m]

Ah, well you seemed most concerned about the sheer quantity of foot-shot-off type bugs you put in, so I thought I'd put your mind at rest about that first. Sadly, that part is inevitable.

As for finding them before anybody else does, I suggest all of the following, which is what I do, because I've found it to work for me:

* Never run outside debugger unless you have previously verified inside the debugger that the run will work - this ensures that you are in a position to fully investigate any problems that might occur. (Some programs can't be verified ahead of time, because they're non-deterministic. (Hopefully due to non-deterministic sources of input, rather than anything in the code!) You just never run these outside the debugger.)

* Never run optimised build if you can help it (this is what the QA department and your users are for :) - again, this ensures you are in a good position to investigate any issues you discover. (Note - you should feel confident about using the debugger with an optimised build, most likely using the disassembly view, but I figure life is too short to be doing this all the time.)

* assert, lots, about everything, particularly pointers into buffers and indexes into arrays.

* -Wall, -W4, -Whatever

* Investigate memory manager's maximally-anally-retentive mode. If it doesn't have one, find a memory manager that does, and use that one instead. Switch it on and fix every complaint it might have.

* Find every debug option and #define for every library you use, and switch all of them on.

* Try to avoid having any multithreading.

* Make sure you know as many dark corners of the language as possible, and commit them to memory, so that you'll be able to spot them when people start making use of them accidentally.

* Add in some kind of crash dump/stack trace/etc. display to your program, so if it should crash during actual use then you stand some chance of getting some useful information back. (Avoid frame pointer omission for this reason.)

Unfortunately I can't guarantee that this will necessarily work, but I've found the above to at least have helped me minimise the sort of creepy, freakish bugs that you only get in C and its ilk.

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