on the edge

computers & technology, books & writing, civilisation & society, cars & stuff


Greg Black

gjb at gbch dot net
Home page
Blog front page


If you’re not living life on the edge, you’re taking up too much space.


FQE30 at speed



Syndication / Categories

  All
   Announce
   Arts
   Books
   Cars
   Family
   House
   Meta
   People
   Places
   Random
   Society
   Software
   Technology
   Writing



Worthy organisations

Amnesty International Australia — global defenders of human rights

global defenders of human rights


Médecins Sans Frontières — help us save lives around the world

Médecins Sans Frontières - help us save lives around the world


Electronic Frontiers Australia — protecting and promoting on-line civil liberties in Australia

Electronic Frontiers Australia



Blogroll

(Coming soon…)



Software resources


GNU Emacs


blosxom


The FreeBSD Project

Fri, 26 May 2006

C is harder than it looks

I recently saw a nice example on a mailing list of the kind of problem dilettantes run into when they play with C. The coder naturally failed to show what he’d done, but described his problem in terms of “what’s wrong with the implementation of sockets in this operating system?” and went on to describe an impossible scenario. This led to a variety of responses from people who like to be seen to be able to help and don’t strongly feel the need to be right.

It was pretty obvious that the original coder had made a standard beginner’s mistake with C syntax and had compounded his error by failing to turn on warnings in his compiler. In essence, he claimed that the socket(2) call would return a descriptor that was already in use because, after opening his socket, data written to the descriptor would appear instead on the standard output.

Fortunately this was seen by somebody who actually knows C in time to stop too much silly speculation. This guy suggested that the coder must have done something like:

    if (sd = socket(AF_INET, SOCK_STREAM, 0) != -1) {
        /* do stuff */
    }

That code will always assign the value 1 to sd, except for the rare case where it’s not possible to open a socket (in which case the reader, having been alerted to the error, will now know what value it will get). Had our coder turned on compiler warnings in gcc, he would have been told, “warning: suggest parentheses around assignment used as truth value” which might not have been enough, but would have suggested that he needed to get help.

Real C programmers have that extra set of parentheses burned into their fingertips and don’t need to think about them—and, on the rare occasions when they do forget them, know instantly what that warning means. And real C programmers always run their compilers with all warnings turned on.

Unfortunately, too many people take a quick look at C, see something quite simple, and decide that they can safely work with it. It is indeed a simple language, but it’s also a demanding language that provides no training wheels for learners. It takes time to really understand it and it takes regular practice to make good use of it. It’s my opinion that the time required is well spent because you then have a very powerful tool at your disposal—but, like all powerful tools, it can hurt the unskilled operator.