-This is ../info/standards.info, produced by makeinfo version 4.6 from
+This is ../info/standards.info, produced by makeinfo version 4.8 from
standards.texi.
START-INFO-DIR-ENTRY
\1f
File: standards.info, Node: Preface, Next: Legal Issues, Prev: Top, Up: Top
-About the GNU Coding Standards
-******************************
+1 About the GNU Coding Standards
+********************************
The GNU Coding Standards were written by Richard Stallman and other GNU
Project volunteers. Their purpose is to make the GNU system clean,
\1f
File: standards.info, Node: Legal Issues, Next: Design Advice, Prev: Preface, Up: Top
-Keeping Free Software Free
-**************************
+2 Keeping Free Software Free
+****************************
This node discusses how you can make sure that GNU software avoids
legal difficulties, and other related issues.
\1f
File: standards.info, Node: Reading Non-Free Code, Next: Contributions, Up: Legal Issues
-Referring to Proprietary Programs
-=================================
+2.1 Referring to Proprietary Programs
+=====================================
Don't in any circumstances refer to Unix source code for or during your
work on GNU! (Or to any other proprietary programs.)
\1f
File: standards.info, Node: Contributions, Next: Trademarks, Prev: Reading Non-Free Code, Up: Legal Issues
-Accepting Contributions
-=======================
+2.2 Accepting Contributions
+===========================
If the program you are working on is copyrighted by the Free Software
Foundation, then when someone else sends you a piece of code to add to
\1f
File: standards.info, Node: Trademarks, Prev: Contributions, Up: Legal Issues
-Trademarks
-==========
+2.3 Trademarks
+==============
Please do not include any trademark acknowledgements in GNU software
packages or documentation.
\1f
File: standards.info, Node: Design Advice, Next: Program Behavior, Prev: Legal Issues, Up: Top
-General Program Design
-**********************
+3 General Program Design
+************************
This node discusses some of the issues you should take into account
when designing your program.
\1f
File: standards.info, Node: Source Language, Next: Compatibility, Up: Design Advice
-Which Languages to Use
-======================
+3.1 Which Languages to Use
+==========================
When you want to use a language that gets compiled and runs at high
speed, the best language to use is C. Using another language is like
\1f
File: standards.info, Node: Compatibility, Next: Using Extensions, Prev: Source Language, Up: Design Advice
-Compatibility with Other Implementations
-========================================
+3.2 Compatibility with Other Implementations
+============================================
With occasional exceptions, utility programs and libraries for GNU
should be upward compatible with those in Berkeley Unix, and upward
\1f
File: standards.info, Node: Using Extensions, Next: Standard C, Prev: Compatibility, Up: Design Advice
-Using Non-standard Features
-===========================
+3.3 Using Non-standard Features
+===============================
Many GNU facilities that already exist support a number of convenient
extensions over the comparable Unix facilities. Whether to use these
\1f
File: standards.info, Node: Standard C, Prev: Using Extensions, Up: Design Advice
-Standard C and Pre-Standard C
-=============================
+3.4 Standard C and Pre-Standard C
+=================================
1989 Standard C is widespread enough now that it is ok to use its
features in new programs. There is one exception: do not ever use the
\1f
File: standards.info, Node: Program Behavior, Next: Writing C, Prev: Design Advice, Up: Top
-Program Behavior for All Programs
-*********************************
+4 Program Behavior for All Programs
+***********************************
This node describes conventions for writing robust software. It also
describes general standards for error messages, the command line
\1f
File: standards.info, Node: Semantics, Next: Libraries, Up: Program Behavior
-Writing Robust Programs
-=======================
+4.1 Writing Robust Programs
+===========================
Avoid arbitrary limits on the length or number of _any_ data structure,
including file names, lines, files, and symbols, by allocating all data
\1f
File: standards.info, Node: Libraries, Next: Errors, Prev: Semantics, Up: Program Behavior
-Library Behavior
-================
+4.2 Library Behavior
+====================
Try to make library functions reentrant. If they need to do dynamic
storage allocation, at least try to avoid any nonreentrancy aside from
\1f
File: standards.info, Node: Errors, Next: User Interfaces, Prev: Libraries, Up: Program Behavior
-Formatting Error Messages
-=========================
+4.3 Formatting Error Messages
+=============================
Error messages from compilers should look like this:
\1f
File: standards.info, Node: User Interfaces, Next: Graphical Interfaces, Prev: Errors, Up: Program Behavior
-Standards for Interfaces Generally
-==================================
+4.4 Standards for Interfaces Generally
+======================================
Please don't make the behavior of a utility depend on the name used to
invoke it. It is useful sometimes to make a link to a utility with a
\1f
File: standards.info, Node: Graphical Interfaces, Next: Command-Line Interfaces, Prev: User Interfaces, Up: Program Behavior
-Standards for Graphical Interfaces
-==================================
+4.5 Standards for Graphical Interfaces
+======================================
When you write a program that provides a graphical user interface,
please make it work with X Windows and the GTK toolkit unless the
\1f
File: standards.info, Node: Command-Line Interfaces, Next: Option Table, Prev: Graphical Interfaces, Up: Program Behavior
-Standards for Command Line Interfaces
-=====================================
+4.6 Standards for Command Line Interfaces
+=========================================
It is a good idea to follow the POSIX guidelines for the command-line
options of a program. The easiest way to do this is to use `getopt' to
\1f
File: standards.info, Node: Option Table, Next: Memory Usage, Prev: Command-Line Interfaces, Up: Program Behavior
-Table of Long Options
-=====================
+4.7 Table of Long Options
+=========================
Here is a table of long options used by GNU programs. It is surely
incomplete, but we aim to list all the options that a new program might
`-q' in Make.
`quiet'
- Used in many programs to inhibit the usual output. *Note:* every
+ Used in many programs to inhibit the usual output. *Note_* every
program accepting `--quiet' should accept `--silent' as a synonym.
`quiet-unshar'
`-T' in `cat'.
`silent'
- Used in many programs to inhibit the usual output. *Note:* every
+ Used in many programs to inhibit the usual output. *Note_* every
program accepting `--silent' should accept `--quiet' as a synonym.
`size'
\1f
File: standards.info, Node: Memory Usage, Next: File Usage, Prev: Option Table, Up: Program Behavior
-Memory Usage
-============
+4.8 Memory Usage
+================
If a program typically uses just a few meg of memory, don't bother
making any effort to reduce memory usage. For example, if it is
\1f
File: standards.info, Node: File Usage, Prev: Memory Usage, Up: Program Behavior
-File Usage
-==========
+4.9 File Usage
+==============
Programs should be prepared to operate when `/usr' and `/etc' are
read-only file systems. Thus, if the program manages log files, lock
\1f
File: standards.info, Node: Writing C, Next: Documentation, Prev: Program Behavior, Up: Top
-Making The Best Use of C
-************************
+5 Making The Best Use of C
+**************************
This node provides advice on how best to use the C language when
writing GNU software.
\1f
File: standards.info, Node: Formatting, Next: Comments, Up: Writing C
-Formatting Your Source Code
-===========================
+5.1 Formatting Your Source Code
+===============================
It is important to put the open-brace that starts the body of a C
function in column zero, and avoid putting any other open-brace or
\1f
File: standards.info, Node: Comments, Next: Syntactic Conventions, Prev: Formatting, Up: Writing C
-Commenting Your Work
-====================
+5.2 Commenting Your Work
+========================
Every program should start with a comment saying briefly what it is for.
Example: `fmt - filter for simple filling of text'.
\1f
File: standards.info, Node: Syntactic Conventions, Next: Names, Prev: Comments, Up: Writing C
-Clean Use of C Constructs
-=========================
+5.3 Clean Use of C Constructs
+=============================
Please explicitly declare the types of all objects. For example, you
should explicitly declare all arguments to functions, and you should
\1f
File: standards.info, Node: Names, Next: System Portability, Prev: Syntactic Conventions, Up: Writing C
-Naming Variables and Functions
-==============================
+5.4 Naming Variables and Functions
+==================================
The names of global variables and functions in a program serve as
comments of a sort. So don't choose terse names--instead, look for
\1f
File: standards.info, Node: System Portability, Next: CPU Portability, Prev: Names, Up: Writing C
-Portability between System Types
-================================
+5.5 Portability between System Types
+====================================
In the Unix world, "portability" refers to porting to different Unix
versions. For a GNU program, this kind of portability is desirable, but
\1f
File: standards.info, Node: CPU Portability, Next: System Functions, Prev: System Portability, Up: Writing C
-Portability between CPUs
-========================
+5.6 Portability between CPUs
+============================
Even GNU systems will differ because of differences among CPU
types--for example, difference in byte ordering and alignment
\1f
File: standards.info, Node: System Functions, Next: Internationalization, Prev: CPU Portability, Up: Writing C
-Calling System Functions
-========================
+5.7 Calling System Functions
+============================
C implementations differ substantially. Standard C reduces but does
not eliminate the incompatibilities; meanwhile, many GNU packages still
#ifndef HAVE_STRRCHR
#define strrchr rindex
#endif
-
+
char *strchr ();
char *strrchr ();
\1f
File: standards.info, Node: Internationalization, Next: Mmap, Prev: System Functions, Up: Writing C
-Internationalization
-====================
+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
\1f
File: standards.info, Node: Mmap, Prev: Internationalization, Up: Writing C
-Mmap
-====
+5.9 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.
\1f
File: standards.info, Node: Documentation, Next: Managing Releases, Prev: Writing C, Up: Top
-Documenting Programs
-********************
+6 Documenting Programs
+**********************
A GNU program should ideally come with full free documentation, adequate
for both reference and tutorial purposes. If the package can be
\1f
File: standards.info, Node: GNU Manuals, Next: Doc Strings and Manuals, Up: Documentation
-GNU Manuals
-===========
+6.1 GNU Manuals
+===============
The preferred document format for the GNU system is the Texinfo
formatting language. Every GNU package should (ideally) have
\1f
File: standards.info, Node: Doc Strings and Manuals, Next: Manual Structure Details, Prev: GNU Manuals, Up: Documentation
-Doc Strings and Manuals
-=======================
+6.2 Doc Strings and Manuals
+===========================
Some programming systems, such as Emacs, provide a documentation string
for each function, command or variable. You may be tempted to write a
\1f
File: standards.info, Node: Manual Structure Details, Next: License for Manuals, Prev: Doc Strings and Manuals, Up: Documentation
-Manual Structure Details
-========================
+6.3 Manual Structure Details
+============================
The title page of the manual should state the version of the programs or
packages documented in the manual. The Top node of the manual should
\1f
File: standards.info, Node: License for Manuals, Next: Manual Credits, Prev: Manual Structure Details, Up: Documentation
-License for Manuals
-===================
+6.4 License for Manuals
+=======================
Please use the GNU Free Documentation License for all GNU manuals that
are more than a few pages long. Likewise for a collection of short
\1f
File: standards.info, Node: Manual Credits, Next: Printed Manuals, Prev: License for Manuals, Up: Documentation
-Manual Credits
-==============
+6.5 Manual Credits
+==================
Please credit the principal human writers of the manual as the authors,
on the title page of the manual. If a company sponsored the work, thank
\1f
File: standards.info, Node: Printed Manuals, Next: NEWS File, Prev: Manual Credits, Up: Documentation
-Printed Manuals
-===============
+6.6 Printed Manuals
+===================
The FSF publishes some GNU manuals in printed form. To encourage sales
of these manuals, the on-line versions of the manual should mention at
the very start that the printed manual is available and should point at
information for getting it--for instance, with a link to the page
-<http://www.gnu.org/order/order.html>. This should not be included in
+`http://www.gnu.org/order/order.html'. This should not be included in
the printed manual, though, because there it is redundant.
It is also useful to explain in the on-line forms of the manual how
\1f
File: standards.info, Node: NEWS File, Next: Change Logs, Prev: Printed Manuals, Up: Documentation
-The NEWS File
-=============
+6.7 The NEWS File
+=================
In addition to its manual, the package should have a file named `NEWS'
which contains a list of user-visible changes worth mentioning. In
\1f
File: standards.info, Node: Change Logs, Next: Man Pages, Prev: NEWS File, Up: Documentation
-Change Logs
-===========
+6.8 Change Logs
+===============
Keep a change log to describe all the changes made to program source
files. The purpose of this is so that people investigating bugs in the
\1f
File: standards.info, Node: Change Log Concepts, Next: Style of Change Logs, Up: Change Logs
-Change Log Concepts
--------------------
+6.8.1 Change Log Concepts
+-------------------------
You can think of the change log as a conceptual "undo list" which
explains how earlier versions were different from the current version.
\1f
File: standards.info, Node: Style of Change Logs, Next: Simple Changes, Prev: Change Log Concepts, Up: Change Logs
-Style of Change Logs
---------------------
+6.8.2 Style of Change Logs
+--------------------------
Here are some simple examples of change log entries, starting with the
header line that says who made the change and when, followed by
and GCC.)
1998-08-17 Richard Stallman <rms@gnu.org>
-
+
* register.el (insert-register): Return nil.
(jump-to-register): Likewise.
-
+
* sort.el (sort-subr): Return nil.
-
+
* tex-mode.el (tex-bibtex-file, tex-file, tex-region):
Restart the tex shell if process is gone or stopped.
(tex-shell-running): New function.
-
+
* expr.c (store_one_arg): Round size up for move_block_to_reg.
(expand_call): Round up when emitting USE insns.
* stmt.c (assign_parms): Round size up for move_block_from_reg.
\1f
File: standards.info, Node: Simple Changes, Next: Conditional Changes, Prev: Style of Change Logs, Up: Change Logs
-Simple Changes
---------------
+6.8.3 Simple Changes
+--------------------
Certain simple kinds of changes don't need much detail in the change
log.
\1f
File: standards.info, Node: Conditional Changes, Next: Indicating the Part Changed, Prev: Simple Changes, Up: Change Logs
-Conditional Changes
--------------------
+6.8.4 Conditional Changes
+-------------------------
C programs often contain compile-time `#if' conditionals. Many changes
are conditional; sometimes you add a new definition which is entirely
\1f
File: standards.info, Node: Indicating the Part Changed, Prev: Conditional Changes, Up: Change Logs
-Indicating the Part Changed
----------------------------
+6.8.5 Indicating the Part Changed
+---------------------------------
Indicate the part of a function which changed by using angle brackets
enclosing an indication of what the changed part does. Here is an entry
\1f
File: standards.info, Node: Man Pages, Next: Reading other Manuals, Prev: Change Logs, Up: Documentation
-Man Pages
-=========
+6.9 Man Pages
+=============
In the GNU project, man pages are secondary. It is not necessary or
expected for every GNU program to have a man page, but some of them do.
\1f
File: standards.info, Node: Reading other Manuals, Prev: Man Pages, Up: Documentation
-Reading other Manuals
-=====================
+6.10 Reading other Manuals
+==========================
There may be non-free books or documentation files that describe the
program you are documenting.
\1f
File: standards.info, Node: Managing Releases, Next: References, Prev: Documentation, Up: Top
-The Release Process
-*******************
+7 The Release Process
+*********************
Making a release is more than just bundling up your source files in a
tar file and putting it up for FTP. You should set up your software so
\1f
File: standards.info, Node: Configuration, Next: Makefile Conventions, Up: Managing Releases
-How Configuration Should Work
-=============================
+7.1 How Configuration Should Work
+=================================
Each GNU distribution should come with a shell script named
`configure'. This script is given arguments which describe the kind of
\1f
File: standards.info, Node: Makefile Conventions, Next: Releases, Prev: Configuration, Up: Managing Releases
-Makefile Conventions
-====================
+7.2 Makefile Conventions
+========================
This node describes conventions for writing the Makefiles for GNU
programs. Using Automake will help you write a Makefile that follows
\1f
File: standards.info, Node: Makefile Basics, Next: Utilities in Makefiles, Up: Makefile Conventions
-General Conventions for Makefiles
----------------------------------
+7.2.1 General Conventions for Makefiles
+---------------------------------------
Every Makefile should contain this line:
\1f
File: standards.info, Node: Utilities in Makefiles, Next: Command Variables, Prev: Makefile Basics, Up: Makefile Conventions
-Utilities in Makefiles
-----------------------
+7.2.2 Utilities in Makefiles
+----------------------------
Write the Makefile commands (and any shell scripts, such as
`configure') to run in `sh', not in `csh'. Don't use any special
\1f
File: standards.info, Node: Command Variables, Next: Directory Variables, Prev: Utilities in Makefiles, Up: Makefile Conventions
-Variables for Specifying Commands
----------------------------------
+7.2.3 Variables for Specifying Commands
+---------------------------------------
Makefiles should provide variables for overriding certain commands,
options, and so on.
\1f
File: standards.info, Node: Directory Variables, Next: Standard Targets, Prev: Command Variables, Up: Makefile Conventions
-Variables for Installation Directories
---------------------------------------
+7.2.4 Variables for Installation Directories
+--------------------------------------------
Installation directories should always be named by variables, so it is
easy to install in a nonstandard place. The standard names for these
\1f
File: standards.info, Node: Standard Targets, Next: Install Command Categories, Prev: Directory Variables, Up: Makefile Conventions
-Standard Targets for Users
---------------------------
+7.2.5 Standard Targets for Users
+--------------------------------
All GNU programs should have the following targets in their Makefiles:
is as follows:
info: foo.info
-
+
foo.info: foo.texi chap1.texi chap2.texi
$(MAKEINFO) $(srcdir)/foo.texi
Generate DVI files for all Texinfo documentation. For example:
dvi: foo.dvi
-
+
foo.dvi: foo.texi chap1.texi chap2.texi
$(TEXI2DVI) $(srcdir)/foo.texi
\1f
File: standards.info, Node: Install Command Categories, Prev: Standard Targets, Up: Makefile Conventions
-Install Command Categories
---------------------------
+7.2.6 Install Command Categories
+--------------------------------
When writing the `install' target, you must classify all the commands
into three categories: normal ones, "pre-installation" commands and
\1f
File: standards.info, Node: Releases, Prev: Makefile Conventions, Up: Managing Releases
-Making Releases
-===============
+7.3 Making Releases
+===================
Package the distribution of `Foo version 69.96' up in a gzipped tar
file with the name `foo-69.96.tar.gz'. It should unpack into a
\1f
File: standards.info, Node: References, Next: Index, Prev: Managing Releases, Up: Top
-References to Non-Free Software and Documentation
-*************************************************
+8 References to Non-Free Software and Documentation
+***************************************************
A GNU program should not recommend use of any non-free program. We
can't stop some people from writing proprietary programs, or stop other
Index
*****
+\0\b[index\0\b]
* Menu:
-* #endif, commenting: Comments.
+* #endif, commenting: Comments. (line 54)
* --help option: Command-Line Interfaces.
+ (line 107)
* --version option: Command-Line Interfaces.
+ (line 34)
* -Wall compiler option: Syntactic Conventions.
-* accepting contributions: Contributions.
+ (line 10)
+* accepting contributions: Contributions. (line 6)
* address for bug reports: Command-Line Interfaces.
-* ANSI C standard: Standard C.
-* arbitrary limits on data: Semantics.
-* autoconf: System Portability.
+ (line 113)
+* ANSI C standard: Standard C. (line 6)
+* arbitrary limits on data: Semantics. (line 6)
+* autoconf: System Portability. (line 23)
* avoiding proprietary code: Reading Non-Free Code.
-* behavior, dependent on program's name: User Interfaces.
+ (line 6)
+* behavior, dependent on program's name: User Interfaces. (line 6)
* binary packages: Install Command Categories.
-* bindir: Directory Variables.
-* braces, in C source: Formatting.
+ (line 80)
+* bindir: Directory Variables. (line 45)
+* braces, in C source: Formatting. (line 6)
* bug reports: Command-Line Interfaces.
+ (line 113)
* canonical name of a program: Command-Line Interfaces.
-* casting pointers to integers: CPU Portability.
-* change logs: Change Logs.
-* change logs, conditional changes: Conditional Changes.
+ (line 41)
+* casting pointers to integers: CPU Portability. (line 67)
+* change logs: Change Logs. (line 6)
+* change logs, conditional changes: Conditional Changes. (line 6)
* change logs, style: Style of Change Logs.
-* command-line arguments, decoding: Semantics.
+ (line 6)
+* command-line arguments, decoding: Semantics. (line 46)
* command-line interface: Command-Line Interfaces.
-* commenting: Comments.
-* compatibility with C and POSIX standards: Compatibility.
+ (line 6)
+* commenting: Comments. (line 6)
+* compatibility with C and POSIX standards: Compatibility. (line 6)
* compiler warnings: Syntactic Conventions.
-* conditional changes, and change logs: Conditional Changes.
-* conditionals, comments for: Comments.
-* configure: Configuration.
-* control-L: Formatting.
+ (line 10)
+* conditional changes, and change logs: Conditional Changes. (line 6)
+* conditionals, comments for: Comments. (line 54)
+* configure: Configuration. (line 6)
+* control-L: Formatting. (line 114)
* conventions for makefiles: Makefile Conventions.
+ (line 6)
* corba: Graphical Interfaces.
-* credits for manuals: Manual Credits.
-* data types, and portability: CPU Portability.
-* declaration for system functions: System Functions.
-* documentation: Documentation.
-* doschk: Names.
-* downloading this manual: Preface.
-* error messages: Semantics.
-* error messages, formatting: Errors.
-* exec_prefix: Directory Variables.
-* expressions, splitting: Formatting.
-* file usage: File Usage.
-* file-name limitations: Names.
-* formatting error messages: Errors.
-* formatting source code: Formatting.
-* formfeed: Formatting.
+ (line 16)
+* credits for manuals: Manual Credits. (line 6)
+* data types, and portability: CPU Portability. (line 6)
+* declaration for system functions: System Functions. (line 21)
+* documentation: Documentation. (line 6)
+* doschk: Names. (line 38)
+* downloading this manual: Preface. (line 23)
+* error messages: Semantics. (line 19)
+* error messages, formatting: Errors. (line 6)
+* exec_prefix: Directory Variables. (line 27)
+* expressions, splitting: Formatting. (line 77)
+* file usage: File Usage. (line 6)
+* file-name limitations: Names. (line 38)
+* formatting error messages: Errors. (line 6)
+* formatting source code: Formatting. (line 6)
+* formfeed: Formatting. (line 114)
* function argument, declaring: Syntactic Conventions.
-* function prototypes: Standard C.
+ (line 6)
+* function prototypes: Standard C. (line 17)
* getopt: Command-Line Interfaces.
+ (line 6)
* gettext: Internationalization.
+ (line 6)
* gnome: Graphical Interfaces.
+ (line 16)
* graphical user interface: Graphical Interfaces.
+ (line 6)
* gtk: Graphical Interfaces.
-* GUILE: Source Language.
+ (line 6)
+* GUILE: Source Language. (line 38)
* implicit int: Syntactic Conventions.
-* impossible conditions: Semantics.
+ (line 6)
+* impossible conditions: Semantics. (line 70)
* internationalization: Internationalization.
-* legal aspects: Legal Issues.
-* legal papers: Contributions.
-* libexecdir: Directory Variables.
-* libraries: Libraries.
-* library functions, and portability: System Functions.
-* license for manuals: License for Manuals.
+ (line 6)
+* legal aspects: Legal Issues. (line 6)
+* legal papers: Contributions. (line 6)
+* libexecdir: Directory Variables. (line 58)
+* libraries: Libraries. (line 6)
+* library functions, and portability: System Functions. (line 6)
+* license for manuals: License for Manuals. (line 6)
* lint: Syntactic Conventions.
-* long option names: Option Table.
+ (line 109)
+* long option names: Option Table. (line 6)
* long-named options: Command-Line Interfaces.
+ (line 12)
* makefile, conventions for: Makefile Conventions.
-* malloc return value: Semantics.
-* man pages: Man Pages.
+ (line 6)
+* malloc return value: Semantics. (line 25)
+* man pages: Man Pages. (line 6)
* manual structure: Manual Structure Details.
-* memory allocation failure: Semantics.
-* memory usage: Memory Usage.
+ (line 6)
+* memory allocation failure: Semantics. (line 25)
+* memory usage: Memory Usage. (line 6)
* message text, and internationalization: Internationalization.
-* mmap: Mmap.
+ (line 29)
+* mmap: Mmap. (line 6)
* multiple variables in a line: Syntactic Conventions.
-* names of variables and functions: Names.
-* NEWS file: NEWS File.
-* non-POSIX systems, and portability: System Portability.
-* non-standard extensions: Using Extensions.
-* NUL characters: Semantics.
-* open brace: Formatting.
-* optional features, configure-time: Configuration.
-* options for compatibility: Compatibility.
-* output device and program's behavior: User Interfaces.
-* packaging: Releases.
-* portability, and data types: CPU Portability.
-* portability, and library functions: System Functions.
-* portability, between system types: System Portability.
-* POSIX compatibility: Compatibility.
-* POSIXLY_CORRECT, environment variable: Compatibility.
+ (line 35)
+* names of variables and functions: Names. (line 6)
+* NEWS file: NEWS File. (line 6)
+* non-POSIX systems, and portability: System Portability. (line 32)
+* non-standard extensions: Using Extensions. (line 6)
+* NUL characters: Semantics. (line 11)
+* open brace: Formatting. (line 6)
+* optional features, configure-time: Configuration. (line 76)
+* options for compatibility: Compatibility. (line 14)
+* output device and program's behavior: User Interfaces. (line 13)
+* packaging: Releases. (line 6)
+* portability, and data types: CPU Portability. (line 6)
+* portability, and library functions: System Functions. (line 6)
+* portability, between system types: System Portability. (line 6)
+* POSIX compatibility: Compatibility. (line 6)
+* POSIXLY_CORRECT, environment variable: Compatibility. (line 21)
* post-installation commands: Install Command Categories.
+ (line 6)
* pre-installation commands: Install Command Categories.
-* prefix: Directory Variables.
-* program configuration: Configuration.
-* program design: Design Advice.
-* program name and its behavior: User Interfaces.
+ (line 6)
+* prefix: Directory Variables. (line 17)
+* program configuration: Configuration. (line 6)
+* program design: Design Advice. (line 6)
+* program name and its behavior: User Interfaces. (line 6)
* program's canonical name: Command-Line Interfaces.
-* programming languges: Source Language.
+ (line 41)
+* programming languges: Source Language. (line 6)
* proprietary programs: Reading Non-Free Code.
-* README file: Releases.
-* references to non-free material: References.
-* releasing: Managing Releases.
-* sbindir: Directory Variables.
-* signal handling: Semantics.
-* spaces before open-paren: Formatting.
+ (line 6)
+* README file: Releases. (line 17)
+* references to non-free material: References. (line 6)
+* releasing: Managing Releases. (line 6)
+* sbindir: Directory Variables. (line 51)
+* signal handling: Semantics. (line 59)
+* spaces before open-paren: Formatting. (line 71)
* standard command-line options: Command-Line Interfaces.
+ (line 31)
* standards for makefiles: Makefile Conventions.
-* string library functions: System Functions.
+ (line 6)
+* string library functions: System Functions. (line 55)
* syntactic conventions: Syntactic Conventions.
-* table of long options: Option Table.
-* temporary files: Semantics.
+ (line 6)
+* table of long options: Option Table. (line 6)
+* temporary files: Semantics. (line 84)
* temporary variables: Syntactic Conventions.
-* texinfo.tex, in a distribution: Releases.
-* TMPDIR environment variable: Semantics.
-* trademarks: Trademarks.
-* where to obtain standards.texi: Preface.
+ (line 23)
+* texinfo.tex, in a distribution: Releases. (line 73)
+* TMPDIR environment variable: Semantics. (line 84)
+* trademarks: Trademarks. (line 6)
+* where to obtain standards.texi: Preface. (line 23)
\1f
Tag Table:
Node: Top\7f980
Node: Preface\7f1582
-Node: Legal Issues\7f3099
-Node: Reading Non-Free Code\7f3559
-Node: Contributions\7f5279
-Node: Trademarks\7f7425
-Node: Design Advice\7f8480
-Node: Source Language\7f8983
-Node: Compatibility\7f10987
-Node: Using Extensions\7f12607
-Node: Standard C\7f14175
-Node: Program Behavior\7f16538
-Node: Semantics\7f17453
-Node: Libraries\7f22138
-Node: Errors\7f23375
-Node: User Interfaces\7f25148
-Node: Graphical Interfaces\7f26745
-Node: Command-Line Interfaces\7f27772
-Node: Option Table\7f33254
-Node: Memory Usage\7f48255
-Node: File Usage\7f49272
-Node: Writing C\7f50012
-Node: Formatting\7f50850
-Node: Comments\7f54905
-Node: Syntactic Conventions\7f58199
-Node: Names\7f61603
-Node: System Portability\7f63788
-Node: CPU Portability\7f66165
-Node: System Functions\7f69413
-Node: Internationalization\7f74612
-Node: Mmap\7f77757
-Node: Documentation\7f78459
-Node: GNU Manuals\7f79560
-Node: Doc Strings and Manuals\7f84609
-Node: Manual Structure Details\7f86154
-Node: License for Manuals\7f87564
-Node: Manual Credits\7f88530
-Node: Printed Manuals\7f88915
-Node: NEWS File\7f89593
-Node: Change Logs\7f90263
-Node: Change Log Concepts\7f91009
-Node: Style of Change Logs\7f92861
-Node: Simple Changes\7f94904
-Node: Conditional Changes\7f96136
-Node: Indicating the Part Changed\7f97546
-Node: Man Pages\7f98061
-Node: Reading other Manuals\7f99677
-Node: Managing Releases\7f100458
-Node: Configuration\7f101210
-Node: Makefile Conventions\7f108107
-Node: Makefile Basics\7f108863
-Node: Utilities in Makefiles\7f112025
-Node: Command Variables\7f114158
-Node: Directory Variables\7f117723
-Node: Standard Targets\7f128605
-Ref: Standard Targets-Footnote-1\7f139853
-Node: Install Command Categories\7f139953
-Node: Releases\7f144523
-Node: References\7f148603
-Node: Index\7f149994
+Node: Legal Issues\7f3103
+Node: Reading Non-Free Code\7f3567
+Node: Contributions\7f5295
+Node: Trademarks\7f7449
+Node: Design Advice\7f8512
+Node: Source Language\7f9019
+Node: Compatibility\7f11031
+Node: Using Extensions\7f12659
+Node: Standard C\7f14235
+Node: Program Behavior\7f16606
+Node: Semantics\7f17525
+Node: Libraries\7f22218
+Node: Errors\7f23463
+Node: User Interfaces\7f25244
+Node: Graphical Interfaces\7f26849
+Node: Command-Line Interfaces\7f27884
+Node: Option Table\7f33374
+Node: Memory Usage\7f48383
+Node: File Usage\7f49408
+Node: Writing C\7f50156
+Node: Formatting\7f50998
+Node: Comments\7f55061
+Node: Syntactic Conventions\7f58363
+Node: Names\7f61775
+Node: System Portability\7f63968
+Node: CPU Portability\7f66353
+Node: System Functions\7f69609
+Node: Internationalization\7f74806
+Node: Mmap\7f77959
+Node: Documentation\7f78669
+Node: GNU Manuals\7f79774
+Node: Doc Strings and Manuals\7f84831
+Node: Manual Structure Details\7f86384
+Node: License for Manuals\7f87802
+Node: Manual Credits\7f88776
+Node: Printed Manuals\7f89169
+Node: NEWS File\7f89855
+Node: Change Logs\7f90533
+Node: Change Log Concepts\7f91287
+Node: Style of Change Logs\7f93151
+Node: Simple Changes\7f95186
+Node: Conditional Changes\7f96430
+Node: Indicating the Part Changed\7f97852
+Node: Man Pages\7f98379
+Node: Reading other Manuals\7f100003
+Node: Managing Releases\7f100794
+Node: Configuration\7f101550
+Node: Makefile Conventions\7f108455
+Node: Makefile Basics\7f109219
+Node: Utilities in Makefiles\7f112393
+Node: Command Variables\7f114538
+Node: Directory Variables\7f118115
+Node: Standard Targets\7f129009
+Ref: Standard Targets-Footnote-1\7f140249
+Node: Install Command Categories\7f140349
+Node: Releases\7f144931
+Node: References\7f149019
+Node: Index\7f150414
\1f
End Tag Table
projects / chise / xemacs-chise.git / blobdiff