System and Language Features to Avoid

Let us first start with some general language rules for how to provide maintainable and portable C code. One of the main objectives is to use the ANSI C and the POSIX.1 standard wherever possible in order to maximum portability. This means that we can not use (unfortunately!) neither objective C nor C++. However, we also want to support original Kernighan Ritchie C compilers and C++ compilers which brings in two important aspects in the coding style:

Reserved words

It is important that there are no reserved words used as variable names, function calls etc in our code. Some of the more common problem makes are listed below but see also Identifiers

• new
• this
• class
• template
• operator
• friend
• catch

Specific Problems

As the world is not ideal, there are some traps that often show up when coding after these standards. This sections gives an overview of the more serious ones.

Syscalls to avoid

Actually, most system calls are to be avoided - they are very often supported via variuous libwww APIs, especially provided by the libwww utilities or core modules. Explicitly the following should not be used:

• printf shouldn't be used to output debug messages, use the libwww HTTrace instead. Also, you may want to use the trace filters
• strdup is not supported on many platforms. Use libwww dynamic strings instead
• sleep put the whole application to sleep and it not very portable. Use libwww timers instead
• memmove is not supported on many any platforms or dump core
• strcasecmp and strncasecmp (use libwww's strcasecomp and strncasecomp)
• malloc, calloc, and realloc (use libwww's memory macros)

Other Problems

malloc

One some platforms malloc() returns NULL if size is 0.

const and static

some versions of gcc have problems with variables declared both static and const.

Preprocessor statements

• Don't indent any preprocessor statements. They must (for some compilers) begin in column 1.
• If you add a comment after preprocessor directives, then it MUST be within a C style comment /* ... */
• Don't use #elif. Basic cpp doesn't know it.

Comments

Don't use // for comments. This is not supported by ANSI C.

Remember that your code should compile without warnings under an ANSI C compiler such as gcc with all warnings enabled BUT this is not enough. The more native compilers you can use the better - gcc is not the only example of an ANSI compiler.