@setfilename standards.info
@settitle GNU Coding Standards
@c This date is automagically updated when you save this file:
-@set lastupdate May 24, 2006
+@set lastupdate November 30, 2006
@c %**end of header
@dircategory GNU organization
2001, 2002, 2003, 2004, 2005, 2006 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
Here is an example of what not to do:
-@example
+@smallexample
printf ("%s is full", capacity > 5000000 ? "disk" : "floppy disk");
-@end example
+@end smallexample
If you apply gettext to all strings, like this,
-@example
+@smallexample
printf (gettext ("%s is full"),
capacity > 5000000 ? gettext ("disk") : gettext ("floppy disk"));
-@end example
+@end smallexample
@noindent
the translator will hardly know that "disk" and "floppy disk" are meant to
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
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
projects / gnulib.git / blobdiff