@setfilename standards.info
@settitle GNU Coding Standards
@c This date is automagically updated when you save this file:
-@set lastupdate April 23, 2006
+@set lastupdate January 21, 2007
@c %**end of header
@dircategory GNU organization
@copying
The GNU coding standards, last updated @value{lastupdate}.
-Copyright (C) 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000,
-2001, 2002, 2003, 2004, 2005, 2006 Free Software Foundation, Inc.
+Copyright @copyright{} 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999,
+2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007 Free Software
+Foundation, Inc.
Permission is granted to copy, distribute and/or modify this document
-under the terms of the GNU Free Documentation License, Version 1.1
+under the terms of the GNU Free Documentation License, Version 1.2
or any later version published by the Free Software Foundation;
with no Invariant Sections, with no
Front-Cover Texts, and with no Back-Cover Texts.
For example, Unix utilities were generally optimized to minimize
memory use; if you go for speed instead, your program will be very
-different. You could keep the entire input file in core and scan it
+different. You could keep the entire input file in memory and scan it
there instead of using stdio. Use a smarter algorithm discovered more
recently than the Unix program. Eliminate use of temporary files. Do
it in one pass instead of two (we did this in the assembler).
(preferably @samp{-o} or @samp{--output}). Even if you allow an output
file name as an ordinary argument for compatibility, try to provide an
option as another way to specify it. This will lead to more consistency
-among GNU utilities, and fewer idiosyncracies for users to remember.
+among GNU utilities, and fewer idiosyncrasies for users to remember.
@cindex standard command-line options
@cindex options, standard command-line
@item socket
Specify a file descriptor for a network server to use for its socket,
instead of opening and binding a new socket. This provides a way to
-run, in a nonpriveledged process, a server that normally needs a
+run, in a non-privileged process, a server that normally needs a
reserved port number.
@item sort
If a program typically uses just a few meg of memory, don't bother making any
effort to reduce memory usage. For example, if it is impractical for
other reasons to operate on files more than a few meg long, it is
-reasonable to read entire input files into core to operate on them.
+reasonable to read entire input files into memory to operate on them.
However, for programs such as @code{cat} or @code{tail}, that can
usefully operate on very large files, it is important to avoid using a
If a program works by lines and could be applied to arbitrary
user-supplied input files, it should keep only a line in memory, because
this is not very hard and users will want to be able to operate on input
-files that are bigger than will fit in core all at once.
+files that are bigger than will fit in memory all at once.
If your program creates complicated data structures, just make them in
-core and give a fatal error if @code{malloc} returns zero.
+memory and give a fatal error if @code{malloc} returns zero.
@node File Usage
@section File Usage
@cindex open brace
@cindex braces, in C source
It is important to put the open-brace that starts the body of a C
-function in column one, and avoid putting any other open-brace or
-open-parenthesis or open-bracket in column one. Several tools look
-for open-braces in column one to find the beginnings of C functions.
-These tools will not work on code not formatted that way.
+function in column one, so that they will start a defun. Several
+tools look for open-braces in column one to find the beginnings of C
+functions. These tools will not work on code not formatted that way.
+
+Avoid putting open-brace, open-parenthesis or open-bracket in column
+one when they are inside a function, so that they won't start a defun.
+The open-brace that starts a @code{struct} body can go in column one
+if you find it useful to treat that definition as a defun.
It is also important for function definitions to start the name of the
function in column one. This helps people to search for function
same declaration. Instead, declare the structure tag separately
and then use it to declare the variables or typedefs.
-Try to avoid assignments inside @code{if}-conditions. For example,
-don't write this:
+Try to avoid assignments inside @code{if}-conditions (assignments
+inside @code{while}-conditions are ok). For example, don't write
+this:
@example
if ((foo = (char *) malloc (sizeof *foo)) == 0)
@example
int c;
@dots{}
-while ((c = getchar()) != EOF)
- write(file_descriptor, &c, 1);
+while ((c = getchar ()) != EOF)
+ write (file_descriptor, &c, 1);
+@end example
+
+@noindent Instead, use @code{unsigned char} as follows. (The @code{unsigned}
+is for portability to unusual systems where @code{char} is signed and
+where there is integer overflow checking.)
+
+@example
+int c;
+while ((c = getchar ()) != EOF)
+ @{
+ unsigned char u = c;
+ write (file_descriptor, &u, 1);
+ @}
@end example
It used to be ok to not worry about the difference between pointers
name} for the package. The text domain name is used to separate the
translations for this package from the translations for other packages.
Normally, the text domain name should be the same as the name of the
-package---for example, @samp{fileutils} for the GNU file utilities.
+package---for example, @samp{coreutils} for the GNU core utilities.
@cindex message text, and internationalization
To enable gettext to work well, avoid writing code that makes
Here is an example of what not to do:
-@example
-printf ("%d file%s processed", nfiles,
- nfiles != 1 ? "s" : "");
-@end example
+@smallexample
+printf ("%s is full", capacity > 5000000 ? "disk" : "floppy disk");
+@end smallexample
-@noindent
-The problem with that example is that it assumes that plurals are made
-by adding `s'. If you apply gettext to the format string, like this,
+If you apply gettext to all strings, like this,
-@example
-printf (gettext ("%d file%s processed"), nfiles,
- nfiles != 1 ? "s" : "");
-@end example
+@smallexample
+printf (gettext ("%s is full"),
+ capacity > 5000000 ? gettext ("disk") : gettext ("floppy disk"));
+@end smallexample
@noindent
-the message can use different words, but it will still be forced to use
-`s' for the plural. Here is a better way:
+the translator will hardly know that "disk" and "floppy disk" are meant to
+be substituted in the other string. Worse, in some languages (like French)
+the construction will not work: the translation of the word "full" depends
+on the gender of the first part of the sentence; it happens to be not the
+same for "disk" as for "floppy disk".
-@example
-printf ((nfiles != 1 ? "%d files processed"
- : "%d file processed"),
- nfiles);
-@end example
-
-@noindent
-This way, you can apply gettext to each of the two strings
-independently:
+Complete sentences can be translated without problems:
@example
-printf ((nfiles != 1 ? gettext ("%d files processed")
- : gettext ("%d file processed")),
- nfiles);
+printf (capacity > 5000000 ? gettext ("disk is full")
+ : gettext ("floppy disk is full"));
@end example
-@noindent
-This can be any method of forming the plural of the word for ``file'', and
-also handles languages that require agreement in the word for
-``processed''.
-
A similar problem appears at the level of sentence structure with this
code:
Adding @code{gettext} calls to this code cannot give correct results for
all languages, because negation in some languages requires adding words
at more than one place in the sentence. By contrast, adding
-@code{gettext} calls does the job straightfowardly if the code starts
+@code{gettext} calls does the job straightforwardly if the code starts
out like this:
@example
: "# Implicit rule search has not been done.\n");
@end example
+Another example is this one:
+
+@example
+printf ("%d file%s processed", nfiles,
+ nfiles != 1 ? "s" : "");
+@end example
+
+@noindent
+The problem with this example is that it assumes that plurals are made
+by adding `s'. If you apply gettext to the format string, like this,
+
+@example
+printf (gettext ("%d file%s processed"), nfiles,
+ nfiles != 1 ? "s" : "");
+@end example
+
+@noindent
+the message can use different words, but it will still be forced to use
+`s' for the plural. Here is a better way, with gettext being applied to
+the two strings independently:
+
+@example
+printf ((nfiles != 1 ? gettext ("%d files processed")
+ : gettext ("%d file processed")),
+ nfiles);
+@end example
+
+@noindent
+But this still doesn't work for languages like Polish, which has three
+plural forms: one for nfiles == 1, one for nfiles == 2, 3, 4, 22, 23, 24, ...
+and one for the rest. The GNU @code{ngettext} function solves this problem:
+
+@example
+printf (ngettext ("%d files processed", "%d file processed", nfiles),
+ nfiles);
+@end example
+
@node Character Set
@section Character Set
variables. The previous descriptions of functions and variables in the
section will also have given information about the topic. A description
written to stand alone would repeat some of that information; this
-redundance looks bad. Meanwhile, the informality that is acceptable in
+redundancy looks bad. Meanwhile, the informality that is acceptable in
a documentation string is totally unacceptable in a manual.
The only good way to use documentation strings in writing a good manual
@cindex optional features, configure-time
Other options are permitted to specify in more detail the software
-or hardware present on the machine, and include or exclude optional
-parts of the package:
+or hardware present on the machine, to include or exclude optional parts
+of the package, or to adjust the name of some tools or arguments to them:
@table @samp
@item --enable-@var{feature}@r{[}=@var{parameter}@r{]}
Do not use a @samp{--with} option to specify the file name to use to
find certain files. That is outside the scope of what @samp{--with}
options are for.
+
+@item @var{variable}=@var{value}
+Set the value of the variable @var{variable} to @var{value}. This is
+used to override the default values of commands or arguments in the
+build process. For example, the user could issue @samp{configure
+CFLAGS=-g CXXFLAGS=-g} to build with debugging information and without
+the default optimization.
+
+Specifying variables as arguments to @code{configure}, like this:
+@example
+./configure CC=gcc
+@end example
+is preferable to setting them in environment variables:
+@example
+CC=gcc ./configure
+@end example
+as it helps to recreate the same configuration later with
+@file{config.status}.
@end table
-All @code{configure} scripts should accept all of these ``detail''
-options, whether or not they make any difference to the particular
-package at hand. In particular, they should accept any option that
-starts with @samp{--with-} or @samp{--enable-}. This is so users will
-be able to configure an entire GNU source tree at once with a single set
-of options.
+All @code{configure} scripts should accept all of the ``detail''
+options and the variable settings, whether or not they make any
+difference to the particular package at hand. In particular, they
+should accept any option that starts with @samp{--with-} or
+@samp{--enable-}. This is so users will be able to configure an
+entire GNU source tree at once with a single set of options.
You will note that the categories @samp{--with-} and @samp{--enable-}
are narrow: they @strong{do not} provide a place for any sort of option
Sometimes a program is free software in itself but depends on a
non-free platform in order to run. For instance, many Java programs
-depend on Sun's Java implementation, and won't run on the GNU Java
-Compiler (which does not yet have all the features) or won't run with
-the GNU Java libraries. To recommend that program is inherently to
-recommend the non-free platform as well; if you should not do the
-latter, then don't do the former.
+depend on the parts of Sun's Java implementation which are not yet
+freely available, and won't run on the GNU Java Compiler (which does
+not yet have all the features) or won't run with the GNU Java
+libraries. We hope this particular problem will be gone in a few
+months, when Sun makes the standard Java libraries freely available,
+but of course the general principle remains: you should not recommend
+programs that depend on non-free software to run.
+
+Some free programs encourage the use of non-free software. A typical
+example is @command{mplayer}. It is free software in itself, and the
+free code can handle some kinds of files. However, @command{mplayer}
+recommends use of non-free codecs for other kinds of files, and users
+that install @command{mplayer} are very likely to install those codecs
+along with it. To recommend @command{mplayer} is, in effect, to
+recommend the non-free codecs. We must not do that, so we cannot
+recommend @command{mplayer} either.
+
+In general, you should also not recommend programs that themselves
+strongly recommend the use of non-free software.
A GNU package should not refer the user to any non-free documentation
for free software. Free documentation that can be included in free
By contrast, it is ok to refer to journal articles and textbooks in
the comments of a program for explanation of how it functions, even
though they be non-free. This is because we don't include such things
-in the GNU system even if we are allowed to--they are outside the
+in the GNU system even if we are allowed to---they are outside the
scope of an operating system project.
Referring to a web site that describes or recommends a non-free