GNU Coding Standards: Richard Stallman, Et Al. Last Updated September 9, 2010
GNU Coding Standards: Richard Stallman, Et Al. Last Updated September 9, 2010
GNU Coding Standards: Richard Stallman, Et Al. Last Updated September 9, 2010
Table of Contents
6 Documenting Programs . . . . . . . . . . . . . . . . . . . . . . . 44
6.1 GNU Manuals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
6.2 Doc Strings and Manuals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
6.3 Manual Structure Details. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
6.4 License for Manuals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
6.5 Manual Credits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
6.6 Printed Manuals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
6.7 The NEWS File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
6.8 Change Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
6.8.1 Change Log Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
6.8.2 Style of Change Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
6.8.3 Simple Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
6.8.4 Conditional Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
6.8.5 Indicating the Part Changed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
6.9 Man Pages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
6.10 Reading other Manuals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Chapter 2: Keeping Free Software Free 1
The GNU Coding Standards were written by Richard Stallman and other GNU Project
volunteers. Their purpose is to make the GNU system clean, consistent, and easy to install.
This document can also be read as a guide to writing portable, robust and reliable programs.
It focuses on programs written in C, but many of the rules and principles are useful even if
you write in another programming language. The rules often state reasons for writing in a
certain way.
If you did not obtain this file directly from the GNU project and recently, please check
for a newer version. You can get the GNU Coding Standards from the GNU web server in
many different formats, including the Texinfo source, PDF, HTML, DVI, plain text, and
more, at: http://www.gnu.org/prep/standards/.
If you are maintaining an official GNU package, in addition to this document, please
read and follow the GNU maintainer information (see Section “Contents” in Information
for Maintainers of GNU Software).
If you want to receive diffs for every change to these GNU documents,
join the mailing list gnustandards-commit@gnu.org, via the web interface at
http://lists.gnu.org/mailman/listinfo/gnustandards-commit. Archives are also
available there.
Please send corrections or suggestions for this document to bug-standards@gnu.org. If
you make a suggestion, please include a suggested new wording for it, to help us consider the
suggestion efficiently. We prefer a context diff to the Texinfo source, but if that’s difficult
for you, you can make a context diff for some other version of this document, or propose it
in any way that makes it clear. The source repository for this document can be found at
http://savannah.gnu.org/projects/gnustandards.
These standards cover the minimum of what is important when writing a GNU package.
Likely, the need for additional standards will come up. Sometimes, you might suggest that
such standards be added to this document. If you think your standards would be generally
useful, please do suggest them.
You should also set standards for your package on many questions not addressed or not
firmly specified here. The most important point is to be self-consistent—try to stick to
the conventions you pick, and try to document them as much as possible. That way, your
program will be more maintainable by others.
The GNU Hello program serves as an example of how to follow the GNU coding standards
for a trivial program. http://www.gnu.org/software/hello/hello.html.
This release of the GNU Coding Standards was last updated September 9, 2010.
This chapter discusses how you can make sure that GNU software avoids legal difficulties,
and other related issues.
Chapter 2: Keeping Free Software Free 2
The very worst thing is if you forget to tell us about the other contributor. We could be
very embarrassed in court some day as a result.
We have more detailed advice for maintainers of programs; if you have reached the stage
of actually maintaining a program for GNU (whether released or not), please ask us for a
copy. It is also available online for your perusal: http://www.gnu.org/prep/maintain/.
2.3 Trademarks
Please do not include any trademark acknowledgements in GNU software packages or doc-
umentation.
Trademark acknowledgements are the statements that such-and-such is a trademark of
so-and-so. The GNU Project has no objection to the basic idea of trademarks, but these
acknowledgements feel like kowtowing, and there is no legal requirement for them, so we
don’t use them.
What is legally required, as regards other people’s trademarks, is to avoid using them in
ways which a reader might reasonably understand as naming or labeling our own programs
or activities. For example, since “Objective C” is (or at least was) a trademark, we made
sure to say that we provide a “compiler for the Objective C language” rather than an
“Objective C compiler”. The latter would have been meant as a shorter way of saying the
former, but it does not explicitly state the relationship, so it could be misinterpreted as
using “Objective C” as a label for the compiler rather than for the language.
Please don’t use “win” as an abbreviation for Microsoft Windows in GNU software or
documentation. In hacker terminology, calling something a “win” is a form of praise. If you
wish to praise Microsoft Windows when speaking on your own, by all means do so, but not
in GNU software. Usually we write the name “Windows” in full, but when brevity is very
important (as in file names and sometimes symbol names), we abbreviate it to “w”. For
instance, the files and functions in Emacs that deal with Windows start with ‘w32’.
• 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 (http://www.gnu.org/
software/guile/), which implements the language Scheme (an especially clean and simple
dialect of Lisp). Guile also includes bindings for GTK+/GNOME, making it practical to
write modern GUI functionality within 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.
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.
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
In Unix, realloc can destroy the storage block if it returns zero. GNU realloc does
not have this bug: if it fails, the original block is unchanged. Feel free to assume the bug
is fixed. If you wish to run your program on Unix, and wish to avoid lossage in this case,
you can use the GNU malloc.
You must expect free to alter the contents of the block that was freed. Anything you
want to fetch from the block, you must fetch before calling free.
If malloc fails in a noninteractive program, make that a fatal error. In an interactive
program (one that reads commands from the user), it is better to abort the command and
return to the command reader loop. This allows the user to kill other processes to free up
virtual memory, and then try the command again.
Use getopt_long to decode arguments, unless the argument syntax makes this unrea-
sonable.
When static storage is to be written in during program execution, use explicit C code
to initialize it. Reserve C initialized declarations for data that will not be changed.
Try to avoid low-level interfaces to obscure Unix data structures (such as file directories,
utmp, or the layout of kernel memory), since these are less likely to work compatibly. If
you need to find all the files in a directory, use readdir or some other high-level interface.
These are supported compatibly by GNU.
The preferred signal handling facilities are the BSD variant of signal, and the posix
sigaction function; the alternative USG signal interface is an inferior design.
Nowadays, using the posix signal functions may be the easiest way to make a program
portable. If you use signal, then on GNU/Linux systems running GNU libc version 1, you
should include ‘bsd/signal.h’ instead of ‘signal.h’, so as to get BSD behavior. It is up
to you whether to support systems where signal has only the USG behavior, or give up
on them.
In error checks that detect “impossible” conditions, just abort. There is usually no point
in printing any message. These checks indicate the existence of bugs. Whoever wants to fix
the bugs will have to read the source code and run a debugger. So explain the problem with
comments in the source. The relevant data will be in variables, which are easy to examine
with the debugger, so there is no point moving them elsewhere.
Do not use a count of errors as the exit status for a program. That does not work, because
exit status values are limited to 8 bits (0 through 255). A single run of the program might
have 256 errors; if you try to return 256 as the exit status, the parent process will see 0 as
the status, and it will appear that the program succeeded.
If you make temporary files, check the TMPDIR environment variable; if that variable is
defined, use the specified directory instead of ‘/tmp’.
In addition, be aware that there is a possible security problem when creating temporary
files in world-writable directories. In C, you can avoid this problem by creating temporary
files in this manner:
fd = open (filename, O_WRONLY | O_CREAT | O_EXCL, 0600);
or by using the mkstemps function from libiberty.
In bash, use set -C to avoid this problem.
Chapter 4: Program Behavior for All Programs 9
Line numbers should start from 1 at the beginning of the file, and column numbers should
start from 1 at the beginning of the line. (Both of these conventions are chosen for compat-
ibility.) Calculate column numbers assuming that space and all ASCII printing characters
have equal width, and assuming tab stops every 8 columns.
The error message can also give both the starting and ending positions of the erroneous
text. There are several formats so that you can avoid redundant information such as a
duplicate line number. Here are the possible formats:
source-file-name:lineno-1.column-1-lineno-2.column-2: message
source-file-name:lineno-1.column-1-column-2: message
source-file-name:lineno-1-lineno-2: message
When an error is spread over several files, you can use this format:
file-1:lineno-1.column-1-file-2:lineno-2.column-2: message
Error messages from other noninteractive programs should look like this:
program:source-file-name:lineno: message
when there is an appropriate source file, or like this:
program: message
when there is no relevant source file.
Chapter 4: Program Behavior for All Programs 10
out.) In addition, consider providing a library interface (for use from C), and perhaps a
keyboard-driven console interface (for use by users from console mode). Once you are doing
the work to provide the functionality and the graphical interface, these won’t be much extra
work.
4.7.1 ‘--version’
The standard --version option should direct the program to print information about its
name, version, origin and legal status, all on standard output, and then exit successfully.
Other options and arguments should be ignored once this is seen, and the program should
not perform its normal function.
The first line is meant to be easy for a program to parse; the version number proper
starts after the last space. In addition, it contains the canonical name for this program, in
this format:
GNU Emacs 19.30
The program’s name should be a constant string; don’t compute it from argv[0]. The idea
is to state the standard or canonical name for the program, not its file name. There are
other ways to find out the precise file name where a command is found in PATH.
If the program is a subsidiary part of a larger package, mention the package name in
parentheses, like this:
emacsserver (GNU Emacs) 19.30
Chapter 4: Program Behavior for All Programs 12
If the package has a version number which is different from this program’s version number,
you can mention the package version number just before the close-parenthesis.
If you need to mention the version numbers of libraries which are distributed separately
from the package which contains this program, you can do so by printing an additional line
of version info for each library you want to mention. Use the same format for these lines as
for the first line.
Please do not mention all of the libraries that the program uses “just for completeness”—
that would produce a lot of unhelpful clutter. Please mention library version numbers only
if you find in practice that they are very important to you in debugging.
The following line, after the version number line or lines, should be a copyright notice.
If more than one copyright notice is called for, put each on a separate line.
Next should follow a line stating the license, preferably using one of abbrevations below,
and a brief statement that the program is free software, and that users are free to copy and
change it. Also mention that there is no warranty, to the extent permitted by law. See
recommended wording below.
It is ok to finish the output with a list of the major authors of the program, as a way of
giving credit.
Here’s an example of output that follows these rules:
GNU hello 2.3
Copyright (C) 2007 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
You should adapt this to your program, of course, filling in the proper year, copyright
holder, name of program, and the references to distribution terms, and changing the rest of
the wording as necessary.
This copyright notice only needs to mention the most recent year in which changes were
made—there’s no need to list the years for previous versions’ changes. You don’t have to
mention the name of the program in these notices, if that is inconvenient, since it appeared
in the first line. (The rules are different for copyright notices in source files; see Section
“Copyright Notices” in Information for GNU Maintainers.)
Translations of the above lines must preserve the validity of the copyright notices (see
Section 5.8 [Internationalization], page 41). If the translation’s character set supports it,
the ‘(C)’ should be replaced with the copyright symbol, as follows:
c
Write the word “Copyright” exactly like that, in English. Do not translate it into another
language. International treaties recognize the English word “Copyright”; translations into
other languages do not have legal significance.
Finally, here is the table of our suggested license abbreviations. Any abbreviation can
be followed by ‘vversion[+]’, meaning that particular version, or later versions with the
‘+’, as shown above.
In the case of exceptions for extra permissions with the GPL, we use ‘/’ for a separator;
the version number can follow the license abbreviation as usual, as in the examples below.
GPL GNU General Public License, http://www.gnu.org/licenses/gpl.html.
Chapter 4: Program Behavior for All Programs 13
4.7.2 ‘--help’
The standard --help option should output brief documentation for how to invoke the
program, on standard output, then exit successfully. Other options and arguments should
be ignored once this is seen, and the program should not perform its normal function.
Near the end of the ‘--help’ option’s output, please place lines giving the email address
for bug reports, the package’s home page (normally http://www.gnu.org/software/pkg,
and the general page for help using GNU programs. The format should be like this:
Report bugs to: mailing-address
pkg home page: <http://www.gnu.org/software/pkg/>
General help using GNU software: <http://www.gnu.org/gethelp/>
It is ok to mention other appropriate mailing lists and web pages.
GCC, for example, plug-ins receive and modify GCC’s internal data structures, and so
clearly form an extended program with the base GCC.
Second, you should require plug-in developers to affirm that their plug-ins are released
under an appropriate license. This should be enforced with a simple programmatic check.
For GCC, again for example, a plug-in must define the global symbol plugin_is_GPL_
compatible, thus asserting that the plug-in is released under a GPL-compatible license
(see Section “Plugins” in GCC Internals).
By adding this check to your program you are not creating a new legal requirement.
The GPL itself requires plug-ins to be free software, licensed compatibly. As long as you
have followed the first rule above to keep plug-ins closely tied to your original program, the
GPL and AGPL already require those plug-ins to be released under a compatible license.
The symbol definition in the plug-in—or whatever equivalent works best in your program—
makes it harder for anyone who might distribute proprietary plug-ins to legally defend
themselves. If a case about this got to court, we can point to that symbol as evidence that
the plug-in developer understood that the license had this requirement.
‘auto-check’
‘-a’ in recode.
‘auto-pager’
‘-a’ in wdiff.
‘auto-reference’
‘-A’ in ptx.
‘avoid-wraps’
‘-n’ in wdiff.
‘background’
For server programs, run in the background.
‘backward-search’
‘-B’ in ctags.
‘basename’
‘-f’ in shar.
‘batch’ Used in GDB.
‘baud’ Used in GDB.
‘before’ ‘-b’ in tac.
‘binary’ ‘-b’ in cpio and diff.
‘bits-per-code’
‘-b’ in shar.
‘block-size’
Used in cpio and tar.
‘blocks’ ‘-b’ in head and tail.
‘break-file’
‘-b’ in ptx.
‘brief’ Used in various programs to make output shorter.
‘bytes’ ‘-c’ in head, split, and tail.
‘c++’ ‘-C’ in etags.
‘catenate’
‘-A’ in tar.
‘cd’ Used in various programs to specify the directory to use.
‘changes’ ‘-c’ in chgrp and chown.
‘classify’
‘-F’ in ls.
‘colons’ ‘-c’ in recode.
‘command’ ‘-c’ in su; ‘-x’ in GDB.
Chapter 4: Program Behavior for All Programs 16
‘extern-only’
‘-g’ in nm.
‘extract’ ‘-i’ in cpio; ‘-x’ in tar.
‘faces’ ‘-f’ in finger.
‘fast’ ‘-f’ in su.
‘fatal-warnings’
‘-E’ in m4.
‘file’ ‘-f’ in gawk, info, make, mt, sed, and tar.
‘field-separator’
‘-F’ in gawk.
‘file-prefix’
‘-b’ in Bison.
‘file-type’
‘-F’ in ls.
‘files-from’
‘-T’ in tar.
‘fill-column’
Used in makeinfo.
‘flag-truncation’
‘-F’ in ptx.
‘fixed-output-files’
‘-y’ in Bison.
‘follow’ ‘-f’ in tail.
‘footnote-style’
Used in makeinfo.
‘force’ ‘-f’ in cp, ln, mv, and rm.
‘force-prefix’
‘-F’ in shar.
‘foreground’
For server programs, run in the foreground; in other words, don’t do anything
special to run the server in the background.
‘format’ Used in ls, time, and ptx.
‘freeze-state’
‘-F’ in m4.
‘fullname’
Used in GDB.
‘gap-size’
‘-g’ in ptx.
Chapter 4: Program Behavior for All Programs 19
‘ignore-matching-lines’
‘-I’ in diff.
‘ignore-space-change’
‘-b’ in diff.
‘ignore-zeros’
‘-i’ in tar.
‘include’ ‘-i’ in etags; ‘-I’ in m4.
‘include-dir’
‘-I’ in make.
‘incremental’
‘-G’ in tar.
‘info’ ‘-i’, ‘-l’, and ‘-m’ in Finger.
‘init-file’
In some programs, specify the name of the file to read as the user’s init file.
‘initial’ ‘-i’ in expand.
‘initial-tab’
‘-T’ in diff.
‘inode’ ‘-i’ in ls.
‘interactive’
‘-i’ in cp, ln, mv, rm; ‘-e’ in m4; ‘-p’ in xargs; ‘-w’ in tar.
‘intermix-type’
‘-p’ in shar.
‘iso-8601’
Used in date
‘jobs’ ‘-j’ in make.
‘just-print’
‘-n’ in make.
‘keep-going’
‘-k’ in make.
‘keep-files’
‘-k’ in csplit.
‘kilobytes’
‘-k’ in du and ls.
‘language’
‘-l’ in etags.
‘less-mode’
‘-l’ in wdiff.
Chapter 4: Program Behavior for All Programs 21
‘level-for-gzip’
‘-g’ in shar.
‘line-bytes’
‘-C’ in split.
‘lines’ Used in split, head, and tail.
‘link’ ‘-l’ in cpio.
‘lint’
‘lint-old’
Used in gawk.
‘list’ ‘-t’ in cpio; ‘-l’ in recode.
‘list’ ‘-t’ in tar.
‘literal’ ‘-N’ in ls.
‘load-average’
‘-l’ in make.
‘login’ Used in su.
‘machine’ Used in uname.
‘macro-name’
‘-M’ in ptx.
‘mail’ ‘-m’ in hello and uname.
‘make-directories’
‘-d’ in cpio.
‘makefile’
‘-f’ in make.
‘mapped’ Used in GDB.
‘max-args’
‘-n’ in xargs.
‘max-chars’
‘-n’ in xargs.
‘max-lines’
‘-l’ in xargs.
‘max-load’
‘-l’ in make.
‘max-procs’
‘-P’ in xargs.
‘mesg’ ‘-T’ in who.
‘message’ ‘-T’ in who.
‘minimal’ ‘-d’ in diff.
Chapter 4: Program Behavior for All Programs 22
‘mixed-uuencode’
‘-M’ in shar.
‘mode’ ‘-m’ in install, mkdir, and mkfifo.
‘modification-time’
‘-m’ in tar.
‘multi-volume’
‘-M’ in tar.
‘name-prefix’
‘-a’ in Bison.
‘nesting-limit’
‘-L’ in m4.
‘net-headers’
‘-a’ in shar.
‘new-file’
‘-W’ in make.
‘no-builtin-rules’
‘-r’ in make.
‘no-character-count’
‘-w’ in shar.
‘no-check-existing’
‘-x’ in shar.
‘no-common’
‘-3’ in wdiff.
‘no-create’
‘-c’ in touch.
‘no-defines’
‘-D’ in etags.
‘no-deleted’
‘-1’ in wdiff.
‘no-dereference’
‘-d’ in cp.
‘no-inserted’
‘-2’ in wdiff.
‘no-keep-going’
‘-S’ in make.
‘no-lines’
‘-l’ in Bison.
‘no-piping’
‘-P’ in shar.
Chapter 4: Program Behavior for All Programs 23
‘one-file-system’
‘-l’ in tar, cp, and du.
‘only-file’
‘-o’ in ptx.
‘only-prof’
‘-f’ in gprof.
‘only-time’
‘-F’ in gprof.
‘options’ ‘-o’ in getopt, fdlist, fdmount, fdmountd, and fdumount.
‘output’ In various programs, specify the output file name.
‘output-prefix’
‘-o’ in shar.
‘override’
‘-o’ in rm.
‘overwrite’
‘-c’ in unshar.
‘owner’ ‘-o’ in install.
‘paginate’
‘-l’ in diff.
‘paragraph-indent’
Used in makeinfo.
‘parents’ ‘-p’ in mkdir and rmdir.
‘pass-all’
‘-p’ in ul.
‘pass-through’
‘-p’ in cpio.
‘port’ ‘-P’ in finger.
‘portability’
‘-c’ in cpio and tar.
‘posix’ Used in gawk.
‘prefix-builtins’
‘-P’ in m4.
‘prefix’ ‘-f’ in csplit.
‘preserve’
Used in tar and cp.
‘preserve-environment’
‘-p’ in su.
Chapter 4: Program Behavior for All Programs 25
‘preserve-modification-time’
‘-m’ in cpio.
‘preserve-order’
‘-s’ in tar.
‘preserve-permissions’
‘-p’ in tar.
‘print’ ‘-l’ in diff.
‘print-chars’
‘-L’ in cmp.
‘print-data-base’
‘-p’ in make.
‘print-directory’
‘-w’ in make.
‘print-file-name’
‘-o’ in nm.
‘print-symdefs’
‘-s’ in nm.
‘printer’ ‘-p’ in wdiff.
‘prompt’ ‘-p’ in ed.
‘proxy’ Specify an HTTP proxy.
‘query-user’
‘-X’ in shar.
‘question’
‘-q’ in make.
‘quiet’ Used in many programs to inhibit the usual output. Every program accepting
‘--quiet’ should accept ‘--silent’ as a synonym.
‘quiet-unshar’
‘-Q’ in shar
‘quote-name’
‘-Q’ in ls.
‘rcs’ ‘-n’ in diff.
‘re-interval’
Used in gawk.
‘read-full-blocks’
‘-B’ in tar.
‘readnow’ Used in GDB.
‘recon’ ‘-n’ in make.
Chapter 4: Program Behavior for All Programs 26
‘record-number’
‘-R’ in tar.
‘recursive’
Used in chgrp, chown, cp, ls, diff, and rm.
‘reference’
‘-r’ in touch.
‘references’
‘-r’ in ptx.
‘regex’ ‘-r’ in tac and etags.
‘release’ ‘-r’ in uname.
‘reload-state’
‘-R’ in m4.
‘relocation’
‘-r’ in objdump.
‘rename’ ‘-r’ in cpio.
‘replace’ ‘-i’ in xargs.
‘report-identical-files’
‘-s’ in diff.
‘reset-access-time’
‘-a’ in cpio.
‘reverse’ ‘-r’ in ls and nm.
‘reversed-ed’
‘-f’ in diff.
‘right-side-defs’
‘-R’ in ptx.
‘same-order’
‘-s’ in tar.
‘same-permissions’
‘-p’ in tar.
‘save’ ‘-g’ in stty.
‘se’ Used in GDB.
‘sentence-regexp’
‘-S’ in ptx.
‘separate-dirs’
‘-S’ in du.
‘separator’
‘-s’ in tac.
Chapter 4: Program Behavior for All Programs 27
‘sequence’
Used by recode to chose files or pipes for sequencing passes.
‘shell’ ‘-s’ in su.
‘show-all’
‘-A’ in cat.
‘show-c-function’
‘-p’ in diff.
‘show-ends’
‘-E’ in cat.
‘show-function-line’
‘-F’ in diff.
‘show-tabs’
‘-T’ in cat.
‘silent’ Used in many programs to inhibit the usual output. Every program accepting
‘--silent’ should accept ‘--quiet’ as a synonym.
‘size’ ‘-s’ in ls.
‘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 non-
privileged process, a server that normally needs a reserved port number.
‘sort’ Used in ls.
‘source’ ‘-W source’ in gawk.
‘sparse’ ‘-S’ in tar.
‘speed-large-files’
‘-H’ in diff.
‘split-at’
‘-E’ in unshar.
‘split-size-limit’
‘-L’ in shar.
‘squeeze-blank’
‘-s’ in cat.
‘start-delete’
‘-w’ in wdiff.
‘start-insert’
‘-y’ in wdiff.
‘starting-file’
Used in tar and diff to specify which file within a directory to start processing
with.
‘statistics’
‘-s’ in wdiff.
Chapter 4: Program Behavior for All Programs 28
‘stdin-file-list’
‘-S’ in shar.
‘stop’ ‘-S’ in make.
‘strict’ ‘-s’ in recode.
‘strip’ ‘-s’ in install.
‘strip-all’
‘-s’ in strip.
‘strip-debug’
‘-S’ in strip.
‘submitter’
‘-s’ in shar.
‘suffix’ ‘-S’ in cp, ln, mv.
‘suffix-format’
‘-b’ in csplit.
‘sum’ ‘-s’ in gprof.
‘summarize’
‘-s’ in du.
‘symbolic’
‘-s’ in ln.
‘symbols’ Used in GDB and objdump.
‘synclines’
‘-s’ in m4.
‘sysname’ ‘-s’ in uname.
‘tabs’ ‘-t’ in expand and unexpand.
‘tabsize’ ‘-T’ in ls.
‘terminal’
‘-T’ in tput and ul. ‘-t’ in wdiff.
‘text’ ‘-a’ in diff.
‘text-files’
‘-T’ in shar.
‘time’ Used in ls and touch.
‘timeout’ Specify how long to wait before giving up on some operation.
‘to-stdout’
‘-O’ in tar.
‘total’ ‘-c’ in du.
‘touch’ ‘-t’ in make, ranlib, and recode.
Chapter 4: Program Behavior for All Programs 29
‘writable’
‘-T’ in who.
‘zeros’ ‘-z’ in gprof.
1.3.6.1.4.1.11591 GNU
1.3.6.1.4.1.11591.2 GnuPG
1.3.6.1.4.1.11591.2.1 notation
1.3.6.1.4.1.11591.2.1.1 pkaAddress
1.3.6.1.4.1.11591.12 digestAlgorithm
1.3.6.1.4.1.11591.12.2 TIGER/192
1.3.6.1.4.1.11591.13 encryptionAlgorithm
1.3.6.1.4.1.11591.13.2 Serpent
1.3.6.1.4.1.11591.13.2.1 Serpent-128-ECB
1.3.6.1.4.1.11591.13.2.2 Serpent-128-CBC
1.3.6.1.4.1.11591.13.2.3 Serpent-128-OFB
1.3.6.1.4.1.11591.13.2.4 Serpent-128-CFB
1.3.6.1.4.1.11591.13.2.21 Serpent-192-ECB
1.3.6.1.4.1.11591.13.2.22 Serpent-192-CBC
1.3.6.1.4.1.11591.13.2.23 Serpent-192-OFB
1.3.6.1.4.1.11591.13.2.24 Serpent-192-CFB
1.3.6.1.4.1.11591.13.2.41 Serpent-256-ECB
Chapter 5: Making The Best Use of C 31
1.3.6.1.4.1.11591.13.2.42 Serpent-256-CBC
1.3.6.1.4.1.11591.13.2.43 Serpent-256-OFB
1.3.6.1.4.1.11591.13.2.44 Serpent-256-CFB
1.3.6.1.4.1.11591.14 CRC algorithms
1.3.6.1.4.1.11591.14.1 CRC 32
It is also important for function definitions to start the name of the function in column
one. This helps people to search for function definitions, and may also help certain tools
recognize them. Thus, using Standard C syntax, the format is this:
static char *
concat (char *s1, char *s2)
{
...
}
or, if you want to use traditional C syntax, format the definition like this:
static char *
concat (s1, s2) /* Name starts in column one here */
char *s1, *s2;
{ /* Open brace in column one here */
...
}
In Standard C, if the arguments don’t fit nicely on one line, split it like this:
int
lots_of_args (int an_integer, long a_long, short a_short,
double a_double, float a_float)
...
The rest of this section gives our recommendations for other aspects of C formatting
style, which is also the default style of the indent program in version 1.2 and newer. It
corresponds to the options
-nbad -bap -nbc -bbo -bl -bli2 -bls -ncdb -nce -cp1 -cs -di2
-ndj -nfc1 -nfca -hnl -i2 -ip5 -lp -pcs -psl -nsc -nsob
We don’t think of these recommendations as requirements, because it causes no problems
for users if two different programs have different formatting styles.
But whatever style you use, please use it consistently, since a mixture of styles within
one program tends to look ugly. If you are contributing changes to an existing program,
please follow the style of that program.
For the body of the function, our recommended style looks like this:
if (x < foo (y, z))
haha = bar[4] + 5;
else
{
while (z)
{
haha += foo (z, z);
z--;
}
return ++x + bar ();
}
We find it easier to read a program when it has spaces before the open-parentheses and
after the commas. Especially after the commas.
Chapter 5: Making The Best Use of C 33
When you split an expression into multiple lines, split it before an operator, not after
one. Here is the right way:
if (foo_this_is_long && bar > win (x, y, z)
&& remaining_condition)
Try to avoid having two operators of different precedence at the same level of indentation.
For example, don’t write this:
mode = (inmode[j] == VOIDmode
|| GET_MODE_SIZE (outmode[j]) > GET_MODE_SIZE (inmode[j])
? outmode[j] : inmode[j]);
Instead, use extra parentheses so that the indentation shows the nesting:
mode = ((inmode[j] == VOIDmode
|| (GET_MODE_SIZE (outmode[j]) > GET_MODE_SIZE (inmode[j])))
? outmode[j] : inmode[j]);
Insert extra parentheses so that Emacs will indent the code properly. For example, the
following indentation looks nice if you do it by hand,
v = rup->ru_utime.tv_sec*1000 + rup->ru_utime.tv_usec/1000
+ rup->ru_stime.tv_sec*1000 + rup->ru_stime.tv_usec/1000;
but Emacs would alter it. Adding a set of parentheses produces something that looks
equally nice, and which Emacs will preserve:
v = (rup->ru_utime.tv_sec*1000 + rup->ru_utime.tv_usec/1000
+ rup->ru_stime.tv_sec*1000 + rup->ru_stime.tv_usec/1000);
Format do-while statements like this:
do
{
a = foo (a);
}
while (a > 0);
Please use formfeed characters (control-L) to divide the program into pages at logical
places (but not within a function). It does not matter just how long the pages are, since
they do not have to fit on a printed page. The formfeeds should appear alone on lines by
themselves.
Please put a comment on each function saying what the function does, what sorts of
arguments it gets, and what the possible values of arguments mean and are used for. It
is not necessary to duplicate in words the meaning of the C argument declarations, if a C
type is being used in its customary fashion. If there is anything nonstandard about its use
(such as an argument of type char * which is really the address of the second character of a
string, not the first), or any possible values that would not work the way one would expect
(such as, that strings containing newlines are not guaranteed to work), be sure to say so.
Also explain the significance of the return value, if there is one.
Please put two spaces after the end of a sentence in your comments, so that the Emacs
sentence commands will work. Also, please write complete sentences and capitalize the first
word. If a lower-case identifier comes at the beginning of a sentence, don’t capitalize it!
Changing the spelling makes it a different identifier. If you don’t like starting a sentence
with a lower case letter, write the sentence differently (e.g., “The identifier lower-case is
. . . ”).
The comment on a function is much clearer if you use the argument names to speak
about the argument values. The variable name itself should be lower case, but write it in
upper case when you are speaking about the value rather than the variable itself. Thus,
“the inode number NODE NUM” rather than “an inode”.
There is usually no purpose in restating the name of the function in the comment before
it, because the reader can see that for himself. There might be an exception when the
comment is so long that the function itself would be off the bottom of the screen.
There should be a comment on each static variable as well, like this:
/* Nonzero means truncate lines in the display;
zero means continue them. */
int truncate_lines;
Every ‘#endif’ should have a comment, except in the case of short conditionals (just a
few lines) that are not nested. The comment should state the condition of the conditional
that is ending, including its sense. ‘#else’ should have a comment describing the condition
and sense of the code that follows. For example:
#ifdef foo
...
#else /* not foo */
...
#endif /* not foo */
#ifdef foo
...
#endif /* foo */
but, by contrast, write the comments this way for a ‘#ifndef’:
#ifndef foo
...
#else /* foo */
...
#endif /* foo */
Chapter 5: Making The Best Use of C 35
#ifndef foo
...
#endif /* not foo */
if (foo)
if (bar)
win ();
else
lose ();
always like this:
if (foo)
{
if (bar)
win ();
else
lose ();
}
If you have an if statement nested inside of an else statement, either write else if on
one line, like this,
if (foo)
...
else if (bar)
...
with its then-part indented like the preceding then-part, or write the nested if within
braces like this:
if (foo)
...
else
{
if (bar)
...
}
Don’t declare both a structure tag and variables or typedefs in the same declaration.
Instead, declare the structure tag separately and then use it to declare the variables or
typedefs.
Try to avoid assignments inside if-conditions (assignments inside while-conditions are
ok). For example, don’t write this:
if ((foo = (char *) malloc (sizeof *foo)) == 0)
fatal ("virtual memory exhausted");
instead, write this:
foo = (char *) malloc (sizeof *foo);
if (foo == 0)
fatal ("virtual memory exhausted");
This example uses zero without a cast as a null pointer constant. This is perfectly fine,
except that a cast is needed when calling a varargs function or when using sizeof.
Chapter 5: Making The Best Use of C 37
Autoconf can provide, simply because most of the programs that need such knowledge have
already been written.
Avoid using the format of semi-internal data bases (e.g., directories) when there is a
higher-level alternative (readdir).
As for systems that are not like Unix, such as MSDOS, Windows, VMS, MVS, and older
Macintosh systems, supporting them is often a lot of work. When that is the case, it is
better to spend your time adding features that will be useful on GNU and GNU/Linux,
rather than on supporting other incompatible systems.
If you do support Windows, please do not abbreviate it as “win”. In hacker terminology,
calling something a “win” is a form of praise. You’re free to praise Microsoft Windows on
your own if you want, but please don’t do this in GNU packages. Instead of abbreviating
“Windows” to “win”, you can write it in full or abbreviate it to “woe” or “w”. In GNU
Emacs, for instance, we use ‘w32’ in file names of Windows-specific files, but the macro for
Windows conditionals is called WINDOWSNT.
It is a good idea to define the “feature test macro” _GNU_SOURCE when compiling your
C files. When you compile on GNU or GNU/Linux, this will enable the declarations of
GNU library extension functions, and that will usually give you a compiler error message if
you define the same function names in some other way in your program. (You don’t have
to actually use these functions, if you prefer to make the program more portable to other
systems.)
But whether or not you use these GNU extensions, you should avoid using their names
for any other meanings. Doing so would make it hard to move your code into other GNU
programs.
void error (int status, int errnum, const char *format, ...);
A simple way to use the Gnulib error module is to obtain the two source
files ‘error.c’ and ‘error.h’ from the Gnulib library source code repository at
http://git.savannah.gnu.org/gitweb/?p=gnulib.git. Here’s a sample use:
#include "error.h"
#include <errno.h>
#include <stdio.h>
FILE *
xfopen (char const *name)
{
FILE *fp = fopen (name, "r");
if (! fp)
error (1, errno, "cannot read %s", name);
return fp;
}
Avoid casting pointers to integers if you can. Such casts greatly reduce portability, and
in most programs they are easy to avoid. In the cases where casting pointers to integers is
essential—such as, a Lisp interpreter which stores type information as well as an address in
one word—you’ll have to make explicit provisions to handle different word sizes. You will
also need to make provision for systems in which the normal range of addresses you can get
from malloc starts far away from zero.
Chapter 5: Making The Best Use of C 40
strchr strrchr
The copy and concatenate functions work fine without a declaration as long as you
don’t use their values. Using their values without a declaration fails on systems where
the width of a pointer differs from the width of int, and perhaps in other cases. It is
trivial to avoid using their values, so do that.
The compare functions and strlen work fine without a declaration on most systems,
possibly all the ones that GNU software runs on. You may find it necessary to declare
them conditionally on a few systems.
The search functions must be declared to return char *. Luckily, there is no variation
in the data type they return. But there is variation in their names. Some systems give
these functions the names index and rindex; other systems use the names strchr and
strrchr. Some systems support both pairs of names, but neither pair works on all
systems.
You should pick a single pair of names and use it throughout your program. (Nowa-
days, it is better to choose strchr and strrchr for new programs, since those are
the standard names.) Declare both of those names as functions returning char *. On
systems which don’t support those names, define them as macros in terms of the other
pair. For example, here is what to put at the beginning of your file (or in a header) if
you want to use the names strchr and strrchr throughout:
#ifndef HAVE_STRCHR
#define strchr index
#endif
#ifndef HAVE_STRRCHR
#define strrchr rindex
#endif
5.8 Internationalization
GNU has a library called GNU gettext that makes it easy to translate the messages in a
program into various languages. You should use this library in every program. Use English
for the messages as they appear in the program, and let gettext provide the way to translate
them into other languages.
Using GNU gettext involves putting a call to the gettext macro around each string that
might need translation—like this:
printf (gettext ("Processing file ‘%s’..."));
This permits GNU gettext to replace the string "Processing file ‘%s’..." with a trans-
lated version.
Once a program uses gettext, please make a point of writing calls to gettext when you
add new strings that call for translation.
Chapter 5: Making The Best Use of C 42
Using GNU gettext in a package involves specifying a text domain name for the pack-
age. 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, ‘coreutils’ for the GNU core utilities.
To enable gettext to work well, avoid writing code that makes assumptions about the
structure of words or sentences. When you want the precise text of a sentence to vary
depending on the data, use two or more alternative string constants each containing a
complete sentences, rather than inserting conditionalized words or phrases into a single
sentence framework.
Here is an example of what not to do:
printf ("%s is full", capacity > 5000000 ? "disk" : "floppy disk");
If you apply gettext to all strings, like this,
printf (gettext ("%s is full"),
capacity > 5000000 ? gettext ("disk") : gettext ("floppy disk"));
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".
Complete sentences can be translated without problems:
printf (capacity > 5000000 ? gettext ("disk is full")
: gettext ("floppy disk is full"));
A similar problem appears at the level of sentence structure with this code:
printf ("# Implicit rule search has%s been done.\n",
f->tried_implicit ? "" : " not");
Adding 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 gettext calls does the job straightforwardly if the code starts out like
this:
printf (f->tried_implicit
? "# Implicit rule search has been done.\n",
: "# Implicit rule search has not been done.\n");
Another example is this one:
printf ("%d file%s processed", nfiles,
nfiles != 1 ? "s" : "");
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,
printf (gettext ("%d file%s processed"), nfiles,
nfiles != 1 ? "s" : "");
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:
printf ((nfiles != 1 ? gettext ("%d files processed")
: gettext ("%d file processed")),
nfiles);
Chapter 5: Making The Best Use of C 43
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
ngettext function solves this problem:
printf (ngettext ("%d files processed", "%d file processed", nfiles),
nfiles);
5.11 Mmap
Don’t assume that mmap either works on all files or fails for all files. It may work on some
files and fail on others.
The proper way to use mmap is to try it on the specific file for which you want to use
it—and if mmap doesn’t work, fall back on doing the job in another way using read and
write.
The reason this precaution is needed is that the GNU kernel (the HURD) provides a
user-extensible file system, in which there can be many different kinds of “ordinary files.”
Chapter 6: Documenting Programs 44
Many of them support mmap, but some do not. It is important to make programs handle all
these kinds of files.
6 Documenting Programs
A GNU program should ideally come with full free documentation, adequate for both refer-
ence and tutorial purposes. If the package can be programmed or extended, the documen-
tation should cover programming or extending it, as well as just using it.
Address the questions that a user will ask when thinking about the job that the program
does. Don’t just tell the reader what each feature can do—say what jobs it is good for, and
show how to use it for those jobs. Explain what is recommended usage, and what kinds of
usage users should avoid.
In general, a GNU manual should serve both as tutorial and reference. It should be
set up for convenient access to each topic through Info, and for reading straight through
(appendixes aside). A GNU manual should give a good introduction to a beginner reading
through from the start, and should also provide all the details that hackers want. The Bison
manual is a good example of this—please take a look at it to see what we mean.
That is not as hard as it first sounds. Arrange each chapter as a logical breakdown of
its topic, but order the sections, and write their text, so that reading the chapter straight
through makes sense. Do likewise when structuring the book into chapters, and when
structuring a section into paragraphs. The watchword is, at each point, address the most
fundamental and important issue raised by the preceding text.
If necessary, add extra chapters at the beginning of the manual which are purely tuto-
rial and cover the basics of the subject. These provide the framework for a beginner to
understand the rest of the manual. The Bison manual provides a good example of how to
do this.
To serve as a reference, a manual should have an Index that list all the functions,
variables, options, and important concepts that are part of the program. One combined
Index should do for a short manual, but sometimes for a complex package it is better to use
multiple indices. The Texinfo manual includes advice on preparing good index entries, see
Section “Making Index Entries” in GNU Texinfo, and see Section “Defining the Entries of
an Index” in GNU Texinfo.
Don’t use Unix man pages as a model for how to write GNU documentation; most
of them are terse, badly structured, and give inadequate explanation of the underlying
concepts. (There are, of course, some exceptions.) Also, Unix man pages use a particular
format which is different from what we use in GNU manuals.
Please include an email address in the manual for where to report bugs in the text of the
manual.
Please do not use the term “pathname” that is used in Unix documentation; use “file
name” (two words) instead. We use the term “path” only for search paths, which are lists
of directory names.
Please do not use the term “illegal” to refer to erroneous input to a computer program.
Please use “invalid” for this, and reserve the term “illegal” for activities prohibited by law.
Please do not write ‘()’ after a function name just to indicate it is a function. foo () is
not a function, it is a function call with no arguments.
A documentation string needs to stand alone—when it appears on the screen, there will
be no other text to introduce or explain it. Meanwhile, it can be rather informal in style.
The text describing a function or variable in a manual must not stand alone; it appears
in the context of a section or subsection. Other text at the beginning of the section should
explain some of the concepts, and should often make some general points that apply to
several functions or 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 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 is to use
them as a source of information for writing good text.
or a batch of changes. If you think that a change calls for explanation, you’re probably
right. Please do explain it—but please put the full explanation in comments in the code,
where people will see it whenever they see the code. For example, “New function” is enough
for the change log when you add a function, because there should be a comment before the
function definition to explain what it does.
In the past, we recommended not mentioning changes in non-software files (manuals,
help files, etc.) in change logs. However, we’ve been advised that it is a good idea to
include them, for the sake of copyright records.
The easiest way to add an entry to ‘ChangeLog’ is with the Emacs command M-x add-
change-log-entry. An entry should have an asterisk, the name of the changed file, and
then in parentheses the name of the changed functions, variables or whatever, followed by
a colon. Then describe the changes you made to that function or variable.
The configure script should write a file named ‘config.status’ which describes which
configuration options were specified when the program was last configured. This file should
be a shell script which, if run, will recreate the same configuration.
The configure script should accept an option of the form ‘--srcdir=dirname’ to specify
the directory where sources are found (if it is not the current directory). This makes it
possible to build the program in a separate directory, so that the actual source directory is
not modified.
If the user does not specify ‘--srcdir’, then configure should check both ‘.’ and ‘..’
to see if it can find the sources. If it finds the sources in one of these places, it should use
them from there. Otherwise, it should report that it cannot find the sources, and should
exit with nonzero status.
Usually the easy way to support ‘--srcdir’ is by editing a definition of VPATH into the
Makefile. Some rules may need to refer explicitly to the specified source directory. To make
this possible, configure can add to the Makefile a variable named srcdir whose value is
precisely the specified directory.
In addition, the ‘configure’ script should take options corresponding to most of the
standard directory variables (see Section 7.2.5 [Directory Variables], page 57). Here is the
list:
--prefix --exec-prefix --bindir --sbindir --libexecdir --sysconfdir
--sharedstatedir --localstatedir --libdir --includedir --oldincludedir
--datarootdir --datadir --infodir --localedir --mandir --docdir
--htmldir --dvidir --pdfdir --psdir
The configure script should also take an argument which specifies the type of system
to build the program for. This argument should look like this:
cpu-company-system
For example, an Athlon-based GNU/Linux system might be ‘i686-pc-linux-gnu’.
The configure script needs to be able to decode all plausible alternatives for how to
describe a machine. Thus, ‘athlon-pc-gnu/linux’ would be a valid alias. There is a shell
script called ‘config.sub’ that you can use as a subroutine to validate system types and
canonicalize aliases.
The configure script should also take the option ‘--build=buildtype’, which
should be equivalent to a plain buildtype argument. For example, ‘configure
--build=i686-pc-linux-gnu’ is equivalent to ‘configure i686-pc-linux-gnu’. When
the build type is not specified by an option or argument, the configure script should
normally guess it using the shell script ‘config.guess’.
Other options are permitted to specify in more detail the software 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:
‘--enable-feature[=parameter]’
Configure the package to build and install an optional user-level facility called
feature. This allows users to choose which optional features to include. Giving
an optional parameter of ‘no’ should omit feature, if it is built by default.
No ‘--enable’ option should ever cause one feature to replace another. No
‘--enable’ option should ever substitute one useful behavior for another useful
Chapter 7: The Release Process 53
behavior. The only proper use for ‘--enable’ is for questions of whether to
build part of the program or exclude it.
‘--with-package’
The package package will be installed, so configure this package to work with
package.
Possible values of package include ‘gnu-as’ (or ‘gas’), ‘gnu-ld’, ‘gnu-libc’,
‘gdb’, ‘x’, and ‘x-toolkit’.
Do not use a ‘--with’ option to specify the file name to use to find certain files.
That is outside the scope of what ‘--with’ options are for.
‘variable=value’
Set the value of the variable variable to value. This is used to override the
default values of commands or arguments in the build process. For example, the
user could issue ‘configure CFLAGS=-g CXXFLAGS=-g’ to build with debugging
information and without the default optimization.
Specifying variables as arguments to configure, like this:
./configure CC=gcc
is preferable to setting them in environment variables:
CC=gcc ./configure
as it helps to recreate the same configuration later with ‘config.status’. How-
ever, both methods should be supported.
All 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 ‘--with-’ or ‘--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 ‘--with-’ and ‘--enable-’ are narrow: they do not
provide a place for any sort of option you might think of. That is deliberate. We want to
limit the possible configuration options in GNU software. We do not want GNU programs
to have idiosyncratic configuration options.
Packages that perform part of the compilation process may support cross-compilation.
In such a case, the host and target machines for the program may be different.
The configure script should normally treat the specified type of system as both the
host and the target, thus producing a program which works for the same type of machine
that it runs on.
To compile a program to run on a host type that differs from the build type, use the
configure option ‘--host=hosttype’, where hosttype uses the same syntax as buildtype.
The host type normally defaults to the build type.
To configure a cross-compiler, cross-assembler, or what have you, you should specify
a target different from the host, using the configure option ‘--target=targettype’. The
syntax for targettype is the same as for the host type. So the command would look like
this:
./configure --host=hosttype --target=targettype
Chapter 7: The Release Process 54
The target type normally defaults to the host type. Programs for which cross-operation
is not meaningful need not accept the ‘--target’ option, because configuring an entire
operating system for cross-operation is not a meaningful operation.
Some programs have ways of configuring themselves automatically. If your program is
set up to do this, your configure script can simply ignore most of its arguments.
in order to allow ‘VPATH’ to work correctly. When the target has multiple dependencies,
using an explicit ‘$(srcdir)’ is the easiest way to make the rule work well. For example,
the target above for ‘foo.1’ is best written as:
foo.1 : foo.man sedscript
sed -f $(srcdir)/sedscript $(srcdir)/foo.man > $@
GNU distributions usually contain some files which are not source files—for example, Info
files, and the output from Autoconf, Automake, Bison or Flex. Since these files normally
appear in the source directory, they should always appear in the source directory, not in
the build directory. So Makefile rules to update them should put the updated files in the
source directory.
However, if a file does not appear in the distribution, then the Makefile should not put
it in the source directory, because building a program in ordinary circumstances should not
modify the source directory in any way.
Try to make the build and installation targets, at least (and all their subtargets) work
correctly with a parallel make.
If you use symbolic links, you should implement a fallback for systems that don’t have
symbolic links.
Additional utilities that can be used via Make variables are:
chgrp chmod chown mknod
It is ok to use other utilities in Makefile portions (or scripts) intended only for particular
systems where you know those utilities exist.
are being installed onto: use the default settings specified here so that all GNU packages
behave identically, allowing the installer to achieve any desired layout.
All installation directories, and their parent directories, should be created (if necessary)
before they are installed into.
These first two variables set the root for the installation. All the other installation
directories should be subdirectories of one of these two, and nothing should be directly
installed into these two directories.
prefix A prefix used in constructing the default values of the variables listed below.
The default value of prefix should be ‘/usr/local’. When building the com-
plete GNU system, the prefix will be empty and ‘/usr’ will be a symbolic link
to ‘/’. (If you are using Autoconf, write it as ‘@prefix@’.)
Running ‘make install’ with a different value of prefix from the one used to
build the program should not recompile the program.
exec_prefix
A prefix used in constructing the default values of some of the variables listed
below. The default value of exec_prefix should be $(prefix). (If you are
using Autoconf, write it as ‘@exec_prefix@’.)
Generally, $(exec_prefix) is used for directories that contain machine-specific
files (such as executables and subroutine libraries), while $(prefix) is used
directly for other directories.
Running ‘make install’ with a different value of exec_prefix from the one
used to build the program should not recompile the program.
Executable programs are installed in one of the following directories.
bindir The directory for installing executable programs that users can run. This should
normally be ‘/usr/local/bin’, but write it as ‘$(exec_prefix)/bin’. (If you
are using Autoconf, write it as ‘@bindir@’.)
sbindir The directory for installing executable programs that can be run from the shell,
but are only generally useful to system administrators. This should normally be
‘/usr/local/sbin’, but write it as ‘$(exec_prefix)/sbin’. (If you are using
Autoconf, write it as ‘@sbindir@’.)
libexecdir
The directory for installing executable programs to be run by other programs
rather than by users. This directory should normally be ‘/usr/local/libexec’,
but write it as ‘$(exec_prefix)/libexec’. (If you are using Autoconf, write
it as ‘@libexecdir@’.)
The definition of ‘libexecdir’ is the same for all packages, so you should in-
stall your data in a subdirectory thereof. Most packages install their data
under ‘$(libexecdir)/package-name/’, possibly within additional subdirec-
tories thereof, such as ‘$(libexecdir)/package-name/machine/version’.
Data files used by the program during its execution are divided into categories in two
ways.
• Some files are normally modified by programs; others are never normally modified
(though users may edit some of these).
Chapter 7: The Release Process 59
• Some files are architecture-independent and can be shared by all machines at a site;
some are architecture-dependent and can be shared only by machines of the same kind
and operating system; others may never be shared between two machines.
This makes for six different possibilities. However, we want to discourage the use of
architecture-dependent files, aside from object files and libraries. It is much cleaner to
make other data files architecture-independent, and it is generally not hard.
Here are the variables Makefiles should use to specify directories to put these various
kinds of files in:
‘datarootdir’
The root of the directory tree for read-only architecture-independent
data files. This should normally be ‘/usr/local/share’, but write it as
‘$(prefix)/share’. (If you are using Autoconf, write it as ‘@datarootdir@’.)
‘datadir’’s default value is based on this variable; so are ‘infodir’, ‘mandir’,
and others.
‘datadir’ The directory for installing idiosyncratic read-only architecture-independent
data files for this program. This is usually the same place as ‘datarootdir’,
but we use the two separate variables so that you can move these program-
specific files without altering the location for Info files, man pages, etc.
This should normally be ‘/usr/local/share’, but write it as
‘$(datarootdir)’. (If you are using Autoconf, write it as ‘@datadir@’.)
The definition of ‘datadir’ is the same for all packages, so you should install
your data in a subdirectory thereof. Most packages install their data under
‘$(datadir)/package-name/’.
‘sysconfdir’
The directory for installing read-only data files that pertain to a single machine–
that is to say, files for configuring a host. Mailer and network configuration
files, ‘/etc/passwd’, and so forth belong here. All the files in this direc-
tory should be ordinary ASCII text files. This directory should normally be
‘/usr/local/etc’, but write it as ‘$(prefix)/etc’. (If you are using Autoconf,
write it as ‘@sysconfdir@’.)
Do not install executables here in this directory (they probably belong in
‘$(libexecdir)’ or ‘$(sbindir)’). Also do not install files that are modified in
the normal course of their use (programs whose purpose is to change the configu-
ration of the system excluded). Those probably belong in ‘$(localstatedir)’.
‘sharedstatedir’
The directory for installing architecture-independent data files which the pro-
grams modify while they run. This should normally be ‘/usr/local/com’,
but write it as ‘$(prefix)/com’. (If you are using Autoconf, write it as
‘@sharedstatedir@’.)
‘localstatedir’
The directory for installing data files which the programs modify while they run,
and that pertain to one specific machine. Users should never need to modify
files in this directory to configure the package’s operation; put such configura-
tion information in separate files that go in ‘$(datadir)’ or ‘$(sysconfdir)’.
Chapter 7: The Release Process 60
‘install-html’
‘install-dvi’
‘install-pdf’
‘install-ps’
These targets install documentation in formats other than Info; they’re intended
to be called explicitly by the person installing the package, if that format is
desired. GNU prefers Info files, so these must be installed by the install
target.
When you have many documentation files to install, we recommend that you
avoid collisions and clutter by arranging for these targets to install in subdi-
rectories of the appropriate installation directory, such as htmldir. As one
example, if your package has multiple manuals, and you wish to install HTML
documentation with many files (such as the “split” mode output by makeinfo
--html), you’ll certainly want to use subdirectories, or two nodes with the same
name in different manuals will overwrite each other.
Chapter 7: The Release Process 64
Please make these install-format targets invoke the commands for the format
target, for example, by making format a dependency.
‘uninstall’
Delete all the installed files—the copies that the ‘install’ and ‘install-*’
targets create.
This rule should not modify the directories where compilation is done, only the
directories where files are installed.
The uninstallation commands are divided into three categories, just like the in-
stallation commands. See Section 7.2.7 [Install Command Categories], page 67.
‘install-strip’
Like install, but strip the executable files while installing them. In simple
cases, this target can use the install target in a simple way:
install-strip:
$(MAKE) INSTALL_PROGRAM=’$(INSTALL_PROGRAM) -s’ \
install
But if the package installs scripts as well as real executables, the install-strip
target can’t just refer to the install target; it has to strip the executables but
not the scripts.
install-strip should not strip the executables in the build directory which are
being copied for installation. It should only strip the copies that are installed.
Normally we do not recommend stripping an executable unless you are sure the
program has no bugs. However, it can be reasonable to install a stripped exe-
cutable for actual execution while saving the unstripped executable elsewhere
in case there is a bug.
‘clean’
Delete all files in the current directory that are normally created by building
the program. Also delete files in other directories if they are created by this
makefile. However, don’t delete the files that record the configuration. Also
preserve files that could be made by building, but normally aren’t because the
distribution comes with them. There is no need to delete parent directories
that were created with ‘mkdir -p’, since they could have existed anyway.
Delete ‘.dvi’ files here if they are not part of the distribution.
‘distclean’
Delete all files in the current directory (or created by this makefile) that are
created by configuring or building the program. If you have unpacked the source
and built the program without creating any other files, ‘make distclean’ should
leave only the files that were in the distribution. However, there is no need to
delete parent directories that were created with ‘mkdir -p’, since they could
have existed anyway.
‘mostlyclean’
Like ‘clean’, but may refrain from deleting a few files that people normally
don’t want to recompile. For example, the ‘mostlyclean’ target for GCC does
not delete ‘libgcc.a’, because recompiling it is rarely necessary and takes a lot
of time.
Chapter 7: The Release Process 65
‘maintainer-clean’
Delete almost everything that can be reconstructed with this Makefile. This
typically includes everything deleted by distclean, plus more: C source files
produced by Bison, tags tables, Info files, and so on.
The reason we say “almost everything” is that running the command ‘make
maintainer-clean’ should not delete ‘configure’ even if ‘configure’ can be
remade using a rule in the Makefile. More generally, ‘make maintainer-clean’
should not delete anything that needs to exist in order to run ‘configure’ and
then begin to build the program. Also, there is no need to delete parent direc-
tories that were created with ‘mkdir -p’, since they could have existed anyway.
These are the only exceptions; maintainer-clean should delete everything else
that can be rebuilt.
The ‘maintainer-clean’ target is intended to be used by a maintainer of the
package, not by ordinary users. You may need special tools to reconstruct
some of the files that ‘make maintainer-clean’ deletes. Since these files are
normally included in the distribution, we don’t take care to make them easy to
reconstruct. If you find you need to unpack the full distribution again, don’t
blame us.
To help make users aware of this, the commands for the special maintainer-
clean target should start with these two:
@echo ’This command is intended for maintainers to use; it’
@echo ’deletes files that may need special tools to rebuild.’
never changed automatically; non-source files are produced from source files by programs
under the control of the Makefile.
The distribution should contain a file named ‘README’ which gives the name of the
package, and a general description of what it does. It is also good to explain the purpose
of each of the first-level subdirectories in the package, if there are any. The ‘README’ file
should either state the version number of the package, or refer to where in the package it
can be found.
The ‘README’ file should refer to the file ‘INSTALL’, which should contain an explanation
of the installation procedure.
The ‘README’ file should also refer to the file which contains the copying conditions. The
GNU GPL, if used, should be in a file called ‘COPYING’. If the GNU LGPL is used, it should
be in a file called ‘COPYING.LESSER’.
Naturally, all the source files must be in the distribution. It is okay to include non-
source files in the distribution, provided they are up-to-date and machine-independent, so
that building the distribution normally will never modify them. We commonly include
non-source files produced by Bison, lex, TEX, and makeinfo; this helps avoid unnecessary
dependencies between our distributions, so that users can install whichever packages they
want to install.
Non-source files that might actually be modified by building and installing the program
should never be included in the distribution. So if you do distribute non-source files, always
make sure they are up to date when you make a new distribution.
Make sure that all the files in the distribution are world-readable, and that directories
are world-readable and world-searchable (octal mode 755). We used to recommend that
all directories in the distribution also be world-writable (octal mode 777), because ancient
versions of tar would otherwise not cope when extracting the archive as an unprivileged
user. That can easily lead to security issues when creating the archive, however, so now we
recommend against that.
Don’t include any symbolic links in the distribution itself. If the tar file contains symbolic
links, then people cannot even unpack it on systems that don’t support symbolic links. Also,
don’t use multiple names for one file in different directories, because certain file systems
cannot handle this and that prevents unpacking the distribution.
Try to make sure that all the file names will be unique on MS-DOS. A name on MS-
DOS consists of up to 8 characters, optionally followed by a period and up to three
characters. MS-DOS will truncate extra characters both before and after the period.
Thus, ‘foobarhacker.c’ and ‘foobarhacker.o’ are not ambiguous; they are truncated
to ‘foobarha.c’ and ‘foobarha.o’, which are distinct.
Include in your distribution a copy of the ‘texinfo.tex’ you used to test print any
‘*.texinfo’ or ‘*.texi’ files.
Likewise, if your program uses small GNU software packages like regex, getopt, obstack,
or termcap, include them in the distribution file. Leaving them out would make the distri-
bution file a little smaller at the expense of possible inconvenience to a user who doesn’t
know what other files to get.
Chapter 8: References to Non-Free Software and Documentation 70
Thus, you should not recommend programs that strongly encourage the use of non-free
software. This is why we do not list mplayer in the Free Software Directory.
A GNU package should not refer the user to any non-free documentation for free software.
Free documentation that can be included in free operating systems is essential for completing
the GNU system, or any free operating system, so encouraging it is a priority; to recommend
use of documentation that we are not allowed to include undermines the impetus for the
community to produce documentation that we can include. So GNU packages should never
recommend non-free documentation.
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 are non-free. This is because
we don’t include such things in the GNU system even if they are free—they are outside the
scope of what a software distribution needs to include.
Referring to a web site that describes or recommends a non-free program is promoting
that program, so please do not make links (or mention by name) web sites that contain
such material. This policy is relevant particularly for the web pages for a GNU package.
Following links from nearly any web site can lead eventually to non-free software; this
is inherent in the nature of the web. So it makes no sense to criticize a site for having such
links. As long as the site does not itself recommend a non-free program, there is no need
to consider the question of the sites that it links to for other reasons.
Thus, for example, you should not refer to AT&T’s web site if that recommends AT&T’s
non-free software packages; you should not refer to a site that links to AT&T’s site presenting
it as a place to get some non-free program, because that link recommends and legitimizes
the non-free program. However, that a site contains a link to AT&T’s web site for some
other purpose (such as long-distance telephone service) is not an objection against it.
providing the same freedoms that the software does. But this License is not limited to
software manuals; it can be used for any textual work, regardless of subject matter or
whether it is published as a printed book. We recommend this License principally for
works whose purpose is instruction or reference.
1. APPLICABILITY AND DEFINITIONS
This License applies to any manual or other work, in any medium, that contains a
notice placed by the copyright holder saying it can be distributed under the terms
of this License. Such a notice grants a world-wide, royalty-free license, unlimited in
duration, to use that work under the conditions stated herein. The “Document”,
below, refers to any such manual or work. Any member of the public is a licensee, and
is addressed as “you”. You accept the license if you copy, modify or distribute the work
in a way requiring permission under copyright law.
A “Modified Version” of the Document means any work containing the Document or
a portion of it, either copied verbatim, or with modifications and/or translated into
another language.
A “Secondary Section” is a named appendix or a front-matter section of the Document
that deals exclusively with the relationship of the publishers or authors of the Document
to the Document’s overall subject (or to related matters) and contains nothing that
could fall directly within that overall subject. (Thus, if the Document is in part a
textbook of mathematics, a Secondary Section may not explain any mathematics.) The
relationship could be a matter of historical connection with the subject or with related
matters, or of legal, commercial, philosophical, ethical or political position regarding
them.
The “Invariant Sections” are certain Secondary Sections whose titles are designated, as
being those of Invariant Sections, in the notice that says that the Document is released
under this License. If a section does not fit the above definition of Secondary then it is
not allowed to be designated as Invariant. The Document may contain zero Invariant
Sections. If the Document does not identify any Invariant Sections then there are none.
The “Cover Texts” are certain short passages of text that are listed, as Front-Cover
Texts or Back-Cover Texts, in the notice that says that the Document is released under
this License. A Front-Cover Text may be at most 5 words, and a Back-Cover Text may
be at most 25 words.
A “Transparent” copy of the Document means a machine-readable copy, represented
in a format whose specification is available to the general public, that is suitable for
revising the document straightforwardly with generic text editors or (for images com-
posed of pixels) generic paint programs or (for drawings) some widely available drawing
editor, and that is suitable for input to text formatters or for automatic translation to
a variety of formats suitable for input to text formatters. A copy made in an otherwise
Transparent file format whose markup, or absence of markup, has been arranged to
thwart or discourage subsequent modification by readers is not Transparent. An image
format is not Transparent if used for any substantial amount of text. A copy that is
not “Transparent” is called “Opaque”.
Examples of suitable formats for Transparent copies include plain ASCII without
markup, Texinfo input format, LaTEX input format, SGML or XML using a publicly
available DTD, and standard-conforming simple HTML, PostScript or PDF designed
Appendix A: GNU Free Documentation License 73
for human modification. Examples of transparent image formats include PNG, XCF
and JPG. Opaque formats include proprietary formats that can be read and edited
only by proprietary word processors, SGML or XML for which the DTD and/or pro-
cessing tools are not generally available, and the machine-generated HTML, PostScript
or PDF produced by some word processors for output purposes only.
The “Title Page” means, for a printed book, the title page itself, plus such following
pages as are needed to hold, legibly, the material this License requires to appear in the
title page. For works in formats which do not have any title page as such, “Title Page”
means the text near the most prominent appearance of the work’s title, preceding the
beginning of the body of the text.
The “publisher” means any person or entity that distributes copies of the Document
to the public.
A section “Entitled XYZ” means a named subunit of the Document whose title either
is precisely XYZ or contains XYZ in parentheses following text that translates XYZ in
another language. (Here XYZ stands for a specific section name mentioned below, such
as “Acknowledgements”, “Dedications”, “Endorsements”, or “History”.) To “Preserve
the Title” of such a section when you modify the Document means that it remains a
section “Entitled XYZ” according to this definition.
The Document may include Warranty Disclaimers next to the notice which states that
this License applies to the Document. These Warranty Disclaimers are considered to
be included by reference in this License, but only as regards disclaiming warranties:
any other implication that these Warranty Disclaimers may have is void and has no
effect on the meaning of this License.
2. VERBATIM COPYING
You may copy and distribute the Document in any medium, either commercially or
noncommercially, provided that this License, the copyright notices, and the license
notice saying this License applies to the Document are reproduced in all copies, and
that you add no other conditions whatsoever to those of this License. You may not use
technical measures to obstruct or control the reading or further copying of the copies
you make or distribute. However, you may accept compensation in exchange for copies.
If you distribute a large enough number of copies you must also follow the conditions
in section 3.
You may also lend copies, under the same conditions stated above, and you may publicly
display copies.
3. COPYING IN QUANTITY
If you publish printed copies (or copies in media that commonly have printed covers) of
the Document, numbering more than 100, and the Document’s license notice requires
Cover Texts, you must enclose the copies in covers that carry, clearly and legibly, all
these Cover Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on
the back cover. Both covers must also clearly and legibly identify you as the publisher
of these copies. The front cover must present the full title with all words of the title
equally prominent and visible. You may add other material on the covers in addition.
Copying with changes limited to the covers, as long as they preserve the title of the
Document and satisfy these conditions, can be treated as verbatim copying in other
respects.
Appendix A: GNU Free Documentation License 74
If the required texts for either cover are too voluminous to fit legibly, you should put
the first ones listed (as many as fit reasonably) on the actual cover, and continue the
rest onto adjacent pages.
If you publish or distribute Opaque copies of the Document numbering more than 100,
you must either include a machine-readable Transparent copy along with each Opaque
copy, or state in or with each Opaque copy a computer-network location from which
the general network-using public has access to download using public-standard network
protocols a complete Transparent copy of the Document, free of added material. If
you use the latter option, you must take reasonably prudent steps, when you begin
distribution of Opaque copies in quantity, to ensure that this Transparent copy will
remain thus accessible at the stated location until at least one year after the last time
you distribute an Opaque copy (directly or through your agents or retailers) of that
edition to the public.
It is requested, but not required, that you contact the authors of the Document well
before redistributing any large number of copies, to give them a chance to provide you
with an updated version of the Document.
4. MODIFICATIONS
You may copy and distribute a Modified Version of the Document under the conditions
of sections 2 and 3 above, provided that you release the Modified Version under precisely
this License, with the Modified Version filling the role of the Document, thus licensing
distribution and modification of the Modified Version to whoever possesses a copy of
it. In addition, you must do these things in the Modified Version:
A. Use in the Title Page (and on the covers, if any) a title distinct from that of the
Document, and from those of previous versions (which should, if there were any,
be listed in the History section of the Document). You may use the same title as
a previous version if the original publisher of that version gives permission.
B. List on the Title Page, as authors, one or more persons or entities responsible for
authorship of the modifications in the Modified Version, together with at least five
of the principal authors of the Document (all of its principal authors, if it has fewer
than five), unless they release you from this requirement.
C. State on the Title page the name of the publisher of the Modified Version, as the
publisher.
D. Preserve all the copyright notices of the Document.
E. Add an appropriate copyright notice for your modifications adjacent to the other
copyright notices.
F. Include, immediately after the copyright notices, a license notice giving the public
permission to use the Modified Version under the terms of this License, in the form
shown in the Addendum below.
G. Preserve in that license notice the full lists of Invariant Sections and required Cover
Texts given in the Document’s license notice.
H. Include an unaltered copy of this License.
I. Preserve the section Entitled “History”, Preserve its Title, and add to it an item
stating at least the title, year, new authors, and publisher of the Modified Version
as given on the Title Page. If there is no section Entitled “History” in the Docu-
ment, create one stating the title, year, authors, and publisher of the Document
Appendix A: GNU Free Documentation License 75
as given on its Title Page, then add an item describing the Modified Version as
stated in the previous sentence.
J. Preserve the network location, if any, given in the Document for public access to
a Transparent copy of the Document, and likewise the network locations given in
the Document for previous versions it was based on. These may be placed in the
“History” section. You may omit a network location for a work that was published
at least four years before the Document itself, or if the original publisher of the
version it refers to gives permission.
K. For any section Entitled “Acknowledgements” or “Dedications”, Preserve the Title
of the section, and preserve in the section all the substance and tone of each of the
contributor acknowledgements and/or dedications given therein.
L. Preserve all the Invariant Sections of the Document, unaltered in their text and
in their titles. Section numbers or the equivalent are not considered part of the
section titles.
M. Delete any section Entitled “Endorsements”. Such a section may not be included
in the Modified Version.
N. Do not retitle any existing section to be Entitled “Endorsements” or to conflict in
title with any Invariant Section.
O. Preserve any Warranty Disclaimers.
If the Modified Version includes new front-matter sections or appendices that qualify
as Secondary Sections and contain no material copied from the Document, you may at
your option designate some or all of these sections as invariant. To do this, add their
titles to the list of Invariant Sections in the Modified Version’s license notice. These
titles must be distinct from any other section titles.
You may add a section Entitled “Endorsements”, provided it contains nothing but
endorsements of your Modified Version by various parties—for example, statements of
peer review or that the text has been approved by an organization as the authoritative
definition of a standard.
You may add a passage of up to five words as a Front-Cover Text, and a passage of up
to 25 words as a Back-Cover Text, to the end of the list of Cover Texts in the Modified
Version. Only one passage of Front-Cover Text and one of Back-Cover Text may be
added by (or through arrangements made by) any one entity. If the Document already
includes a cover text for the same cover, previously added by you or by arrangement
made by the same entity you are acting on behalf of, you may not add another; but
you may replace the old one, on explicit permission from the previous publisher that
added the old one.
The author(s) and publisher(s) of the Document do not by this License give permission
to use their names for publicity for or to assert or imply endorsement of any Modified
Version.
5. COMBINING DOCUMENTS
You may combine the Document with other documents released under this License,
under the terms defined in section 4 above for modified versions, provided that you
include in the combination all of the Invariant Sections of all of the original documents,
unmodified, and list them all as Invariant Sections of your combined work in its license
notice, and that you preserve all their Warranty Disclaimers.
Appendix A: GNU Free Documentation License 76
The combined work need only contain one copy of this License, and multiple identical
Invariant Sections may be replaced with a single copy. If there are multiple Invariant
Sections with the same name but different contents, make the title of each such section
unique by adding at the end of it, in parentheses, the name of the original author or
publisher of that section if known, or else a unique number. Make the same adjustment
to the section titles in the list of Invariant Sections in the license notice of the combined
work.
In the combination, you must combine any sections Entitled “History” in the vari-
ous original documents, forming one section Entitled “History”; likewise combine any
sections Entitled “Acknowledgements”, and any sections Entitled “Dedications”. You
must delete all sections Entitled “Endorsements.”
6. COLLECTIONS OF DOCUMENTS
You may make a collection consisting of the Document and other documents released
under this License, and replace the individual copies of this License in the various
documents with a single copy that is included in the collection, provided that you
follow the rules of this License for verbatim copying of each of the documents in all
other respects.
You may extract a single document from such a collection, and distribute it individu-
ally under this License, provided you insert a copy of this License into the extracted
document, and follow this License in all other respects regarding verbatim copying of
that document.
7. AGGREGATION WITH INDEPENDENT WORKS
A compilation of the Document or its derivatives with other separate and independent
documents or works, in or on a volume of a storage or distribution medium, is called
an “aggregate” if the copyright resulting from the compilation is not used to limit the
legal rights of the compilation’s users beyond what the individual works permit. When
the Document is included in an aggregate, this License does not apply to the other
works in the aggregate which are not themselves derivative works of the Document.
If the Cover Text requirement of section 3 is applicable to these copies of the Document,
then if the Document is less than one half of the entire aggregate, the Document’s Cover
Texts may be placed on covers that bracket the Document within the aggregate, or the
electronic equivalent of covers if the Document is in electronic form. Otherwise they
must appear on printed covers that bracket the whole aggregate.
8. TRANSLATION
Translation is considered a kind of modification, so you may distribute translations
of the Document under the terms of section 4. Replacing Invariant Sections with
translations requires special permission from their copyright holders, but you may
include translations of some or all Invariant Sections in addition to the original versions
of these Invariant Sections. You may include a translation of this License, and all the
license notices in the Document, and any Warranty Disclaimers, provided that you
also include the original English version of this License and the original versions of
those notices and disclaimers. In case of a disagreement between the translation and
the original version of this License or a notice or disclaimer, the original version will
prevail.
Appendix A: GNU Free Documentation License 77
Index
# C
#endif, commenting . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 canonical name of a program . . . . . . . . . . . . . . . . . . 11
casting pointers to integers . . . . . . . . . . . . . . . . . . . . 39
CGI programs, standard options for . . . . . . . . . . . . 11
- change logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
‘--help’ output. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 change logs, conditional changes . . . . . . . . . . . . . . . 49
‘--version’ output . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 change logs, style . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
‘-Wall’ compiler option . . . . . . . . . . . . . . . . . . . . . . . . 35 character set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
clang . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
command-line arguments, decoding . . . . . . . . . . . . . 8
A command-line interface . . . . . . . . . . . . . . . . . . . . . . . . 11
accepting contributions . . . . . . . . . . . . . . . . . . . . . . . . . 2 commenting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
address for bug reports . . . . . . . . . . . . . . . . . . . . . . . . 13 compatibility with C and posix standards . . . . . . . 4
ansi C standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 compiler warnings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
arbitrary limits on data . . . . . . . . . . . . . . . . . . . . . . . . . 7 conditional changes, and change logs . . . . . . . . . . . 49
ASCII characters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 conditionals, comments for . . . . . . . . . . . . . . . . . . . . . 34
autoconf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 configure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
avoiding proprietary code . . . . . . . . . . . . . . . . . . . . . . . 2 control-L . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
conventions for makefiles . . . . . . . . . . . . . . . . . . . . . . . 54
CORBA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
B credits for manuals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
behavior, dependent on program’s name . . . . . . . 10
binary packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 D
bindir . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
D-bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
braces, in C source . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
data types, and portability. . . . . . . . . . . . . . . . . . . . . 38
bug reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
declaration for system functions. . . . . . . . . . . . . . . . 40
bug-standards@gnu.org email address . . . . . . . . . . 1
DESTDIR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Index 80
programming languages . . . . . . . . . . . . . . . . . . . . . . . . . 3 T
proprietary programs . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
table of long options . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
temporary files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Q temporary variables . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
‘texinfo.tex’, in a distribution . . . . . . . . . . . . . . . . 69
quote characters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
TMPDIR environment variable . . . . . . . . . . . . . . . . . . . . 8
trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
R
‘README’ file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 U
references to non-free material . . . . . . . . . . . . . . . . . 70
releasing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 user interface styles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
S V
Savannah repository for gnustandards . . . . . . . . . . . 1 valgrind . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
sbindir . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
signal handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
SNMP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
spaces before open-paren . . . . . . . . . . . . . . . . . . . . . . 32
W
staged installs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 where to obtain standards.texi . . . . . . . . . . . . . . . . 1
standard command-line options . . . . . . . . . . . . . . . . 11
standards for makefiles . . . . . . . . . . . . . . . . . . . . . . . . 54
string library functions . . . . . . . . . . . . . . . . . . . . . . . . 40 X
syntactic conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 35 X.509 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30