Go to the first, previous, next, last section, table of contents.

# General Program Design

This chapter discusses some of the issues you should take into account when designing your program.

- Compatibility: Compatibility with other implementations
- Using Extensions: Using non-standard features
- ANSI C: Using ANSI C features
- Source Language: Using languages other than C

## Compatibility with Other Implementations

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 environment variable `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.

## Using Non-standard Features

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" `INLINE` and define that as a macro to expand into either `inline` or 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.

## ANSI C and pre-ANSI C

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 Languages Other Than 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:

- It is okay to use a special language if the same program contains an interpreter for that language. For example, if your program links with GUILE, it is ok to write part of the program in Scheme or another language supported by GUILE.
- It is okay to use another language in a tool specifically intended for use with that language. This is okay because the only people who want to build the tool will be those who have installed the other language anyway.
- If an application is not of extremely widespread interest, then perhaps it's not important if the application is inconvenient to install.

Go to the first, previous, next, last section, table of contents.