Secure, Efficient and Easy C programming

cras writes "Feeling a bit of masochist today.. First in the morning I wrote Secure, Efficient and Easy C Programming Mini-HOWTO. And since I already spent a few hours with it, I figured I might just as well see what Slashdot people would think about it."

Comments

Re:a little short??

[cras]

It does look like a good start, add a few more chapters and you will be halfway there...

Sorry, but I think this is about all I have to say. Secure Programming HOWTO should take care of the rest.

stack allocation??

[hanwen]

(yawn)

it starts off with denouncing GC as oldfashioned, and then proceeds to tout stack-based allocation, which has been available for ages as the alloca() function (which also has portability problems.)

imho, you should use the Boehm Garbage collector, unless you have code that must be guaranteed to be free of space leaks.

scanf and friends

[usrerco]

No such document should be without mention of scanf(3) misuse, and gets(3) use at all.

Regarding scanf(3), many people don't realize this is Bad:

• char cmd[80], arg[80];
  scanf("%s %s", cmd, arg); // BAD
  

This is Good:

• char cmd[80], arg[80];
  scanf("%79s %79s", cmd, arg); // GOOD
  

This prevents a buffer overrun if a word contains 80 or more consecutive non-white characters.

Ditto for sscanf(3) and fscanf(3). Never forget the N+1 when declaring the arrays (eg. char s[80] vs %79s) to leave room for the NULL.

Here's a good command to run on all your .c files to find such problems:

• egrep 'scanf(.*%s' *.c

..any lines that match are a potential problem.

And in a document like this, *definitely* point out the whole gets(3) problem; the granddaddy of them all. Never use gets(3), period. Use fgets(3) instead.

The gets(3) interface is inherently insecure; a problem waiting to happen by its mere existence. Any code that uses it is broken.

There are probably some others (someone mentioned strcpy) I'll try to post more if I think of them.

I send you this post to have your advice

[denshi]

Prototyping in a higher-level language (c# is easy, java everyone knows) is a superb idea, provided you
- can release the final product as interpreted, with slow execution speed
- can afford the time to port all to C, in which case DO, this is an excellent way to make a watertight C program

Sir! I wish to introduce to you to the strange new-fangled notion of compiled high-level languages! Yes, languages with higher-than-C-level abstractions have been sneakily producing native machine code for some time now. Some of the most popular are listed below:

• O'Caml is a marvel of strongly typed object orientation, but you'd hardly know it from using it -- there are almost no C-style type declarations; as a ML child, O'Caml uses type inferencing to prove powerful assertions about program validity and improve programmer convenience. It's compiled! And if you watch the ICFP's, you might note that it consistently beats C compilers for speed of execution. '92, if I recall.
• I never really bought OO, so S/ML is fine by me. Still compiled, since 1984.
• And they both descend from ML, started in 1973.
• Lisp was compiled in 59 or 62 (mccarthy or 1.5, chose your valid date). But then, I suppose it'd have to be compiled, since the notion of interpreted code hadn't been concieved of yet!
• Erlang is the last, best, word in concurrent programming. If you want to write a high throughput, reliable threaded application, you shouldn't even think of the word 'C'. This broke out of its lab in '87, first compiler in '91.
• Scheme is often thought of as a testbed for interpreted language concepts, but even it can be compiled, and with concepts such as continuations that can actually make a C programmer's head explode! Since 1982, commercial grade compilers have been available.
• Even haskell is compiled, but as monadic programming is less than 10 years old, no one knows how to always write really fast code in it yet. Leave your number, we'll call you in 2034, right before you gear up to deal with your year 2038 rollover crisis.

Welcome to the late 1970's! We look forward to your eventual arrival in the 80's and early 90's. Please enjoy your stay!

ps. As modern coding is more about the manipulation of very complex structures, rather than how to say, walk a linked list; a higher level language, with native support for more complex constructs, has the potential for creating much faster applications than something on the level of C. The reason being is that the h/l compiler can reason about, and thus optimize over, larger components than the C compiler.