3. General Program Design

This No value for CHAPTER discusses some of the issues you should take into account when designing your program.

3.1 Which Languages to Use

When you want to use a language that gets compiled and runs at high speed, the best language to use is C. Using another language 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. For example, if you write your program in C++, people will have to install the GNU C++ compiler in order to compile your program.

C has one other advantage over C++ and other compiled languages: more people know C, so more people will find it easy to read and modify the program if it is written in C.

So in general it is much better to use C, rather than the comparable alternatives.

But there are two exceptions to that conclusion:

• It is no problem to use another language to write a tool specifically intended for use with that language. That is because the only people who want to build the tool will be those who have installed the other language anyway.
• If an application is of interest only to a narrow part of the community, then the question of which language it is written in has less effect on other people, so you may as well please yourself.

Many programs are designed to be extensible: they include an interpreter for a language that is higher level than C. Often much of the program is written in that language, too. The Emacs editor pioneered this technique.

The standard extensibility interpreter for GNU software is GUILE, which implements the language Scheme (an especially clean and simple dialect of Lisp). http://www.gnu.org/software/guile/. We don’t reject programs written in other “scripting languages” such as Perl and Python, but using GUILE is very important for the overall consistency of the GNU system.

3.2 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 Standard C if Standard 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.

Standard 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. So you should try to redesign its interface to make it upward compatible.

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 are welcome regardless of whether there is any precedent for them.

3.3 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. Using GNU extensions in such programs would make many users unhappy, so we don’t do that.

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 extremely troublesome in certain cases.

3.4 Standard C and Pre-Standard C

1989 Standard C is widespread enough now that it is ok to use its features in new programs. There is one exception: do not ever use the “trigraph” feature of Standard C.

1999 Standard C is not widespread yet, so please do not require its features in programs. It is ok to use its features if they are present.

However, it is easy to support pre-standard compilers in most programs, so if you know how to do that, feel free. If a program you are maintaining has such support, you should try to keep it working.

To support pre-standard C, instead of writing function definitions in standard prototype form,

int
foo (int x, int y)
…

write the definition in pre-standard 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 prototypes in all the files where the function is called. And once you have the declaration, you normally lose nothing by writing the function definition in the pre-standard style.

This technique does not work for integer types narrower than int. If you think of an argument as being of a type narrower than int, declare it as int instead.

There are a few special cases where this technique is hard to use. For example, if a function argument needs to hold the system type dev_t, you run into trouble, because dev_t is shorter than int on some machines; but you cannot use int instead, because dev_t is wider than int on some machines. There is no type you can safely use on all machines in a non-standard definition. The only way to support non-standard C and pass such an argument is to check the width of dev_t using Autoconf and choose the argument type accordingly. This may not be worth the trouble.

In order to support pre-standard compilers that do not recognize prototypes, you may want to use a preprocessor macro like this:

/* Declare the prototype for a general external function.  */
#if defined (__STDC__) || defined (WINDOWSNT)
#define P_(proto) proto
#else
#define P_(proto) ()
#endif

This document was generated by Aidan Kehoe on December 27, 2016 using texi2html 1.82.