This chapter discusses some of the issues you should take into account when designing your program.
With occasional exceptions, utility programs and libraries for GNU should be upward compatible with those in Berkeley Unix, and upward compatible with ANSI C if ANSI C specifies their behavior, and upward compatible with POSIX if POSIX specifies their behavior.
When these standards conflict, it is useful to offer compatibility modes for each of them.
ANSI C and POSIX prohibit many kinds of extensions. Feel free to make the extensions anyway, and include a `--ansi', `--posix', or `--compatible' option to turn them off. However, if the extension has a significant chance of breaking any real programs or scripts, then it is not really upward compatible. Try to redesign its interface.
Many GNU programs suppress extensions that conflict with POSIX if the
POSIXLY_CORRECT is defined (even if it is
defined with a null value). Please make your program recognize this
variable if appropriate.
When a feature is used only by users (not by programs or command
files), and it is done poorly in Unix, feel free to replace it
completely with something totally different and better. (For example,
vi is replaced with Emacs.) But it is nice to offer a compatible
feature as well. (There is a free
vi clone, so we offer it.)
Additional useful features not in Berkeley Unix are welcome. Additional programs with no counterpart in Unix may be useful, but our first priority is usually to duplicate what Unix already has.
Many GNU facilities that already exist support a number of convenient extensions over the comparable Unix facilities. Whether to use these extensions in implementing your program is a difficult question.
On the one hand, using the extensions can make a cleaner program. On the other hand, people will not be able to build the program unless the other GNU tools are available. This might cause the program to work on fewer kinds of machines.
With some extensions, it might be easy to provide both alternatives.
For example, you can define functions with a "keyword"
and define that as a macro to expand into either
nothing, depending on the compiler.
In general, perhaps it is best not to use the extensions if you can straightforwardly do without them, but to use the extensions if they are a big improvement.
An exception to this rule are the large, established programs (such as Emacs) which run on a great variety of systems. Such programs would be broken by use of GNU extensions.
Another exception is for programs that are used as part of compilation: anything that must be compiled with other compilers in order to bootstrap the GNU compilation facilities. If these require the GNU compiler, then no one can compile them without having them installed already. That would be no good.
Do not ever use the "trigraph" feature of ANSI C.
ANSI C is widespread enough now that it is ok to write new programs that use ANSI C features (and therefore will not work in non-ANSI compilers). And if a program is already written in ANSI C, there's no need to convert it to support non-ANSI compilers.
However, it is easy to support non-ANSI compilers in most programs, so you might still consider doing so when you write a program. Instead of writing function definitions in ANSI prototype form,
int foo (int x, int y) ...
write the definition in pre-ANSI style like this,
int foo (x, y) int x, y; ...
and use a separate declaration to specify the argument prototype:
int foo (int, int);
You need such a declaration anyway, in a header file, to get the benefit of ANSI C prototypes in all the files where the function is called. And once you have it, you lose nothing by writing the function definition in the pre-ANSI style.
If you don't know non-ANSI C, there's no need to learn it; just write in ANSI C.
Using a language other than C is like using a non-standard feature: it will cause trouble for users. Even if GCC supports the other language, users may find it inconvenient to have to install the compiler for that other language in order to build your program. So please write in C.
There are three exceptions for this rule:
Go to the first, previous, next, last section, table of contents.