@setfilename standards.info
@settitle GNU Coding Standards
@c This date is automagically updated when you save this file:
-@set lastupdate April 17, 1998
+@set lastupdate May 4, 1998
@c %**end of header
@ifinfo
With occasional exceptions, utility programs and libraries for GNU
should be upward compatible with those in Berkeley Unix, and upward
compatible with @sc{ansi} C if @sc{ansi} C specifies their behavior, and
-upward compatible with @sc{POSIX} if @sc{POSIX} specifies their
+upward compatible with @sc{posix} if @sc{posix} specifies their
behavior.
When these standards conflict, it is useful to offer compatibility
modes for each of them.
-@sc{ansi} C and @sc{POSIX} prohibit many kinds of extensions. Feel free
+@sc{ansi} C and @sc{posix} prohibit many kinds of extensions. Feel free
to make the extensions anyway, and include a @samp{--ansi},
@samp{--posix}, or @samp{--compatible} option to turn them off.
However, if the extension has a significant chance of breaking any real
programs or scripts, then it is not really upward compatible. Try to
redesign its interface.
-Many GNU programs suppress extensions that conflict with POSIX if the
+Many GNU programs suppress extensions that conflict with @sc{posix} if the
environment variable @code{POSIXLY_CORRECT} is defined (even if it is
defined with a null value). Please make your program recognize this
variable if appropriate.
in a directory, use @code{readdir} or some other high-level interface.
These will be supported compatibly by GNU.
-By default, the GNU system will provide the signal handling functions of
-@sc{BSD} and of @sc{POSIX}. So GNU software should be written to use
-these.
+The preferred signal handling facilities are the BSD variant of
+@code{signal}, andthe @sc{posix} @code{sigaction} function; the
+alternative USG @code{signal} interface is an inferior design.
+
+Nowadays, using the @sc{posix} signal functions may be the easiest way
+to make a program portable. If you use @code{signal}, then on GNU/Linux
+systems running GNU libc version 1, you should include
+@file{bsd/signal.h} instead of @file{signal.h}, so as to get BSD
+behavior. It is up to you whether to support systems where
+@code{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
like @code{ls} except that its default output format is always
multi-column format.
-It is a good idea to follow the @sc{POSIX} guidelines for the
+It is a good idea to follow the @sc{posix} guidelines for the
command-line options of a program. The easiest way to do this is to use
@code{getopt} to parse them. Note that the GNU version of @code{getopt}
will normally permit options anywhere among the arguments unless the
-special argument @samp{--} is used. This is not what @sc{POSIX}
+special argument @samp{--} is used. This is not what @sc{posix}
specifies; it is a GNU extension.
Please define long-named options that are equivalent to the
Make sure that no file name in the distribution is more than 14
characters long. Likewise, no file created by building the program
should have a name longer than 14 characters. The reason for this is
-that some systems adhere to a foolish interpretation of the POSIX
+that some systems adhere to a foolish interpretation of the @sc{posix}
standard, and refuse to open a longer name, rather than truncating as
they did in the past.
@setfilename standards.info
@settitle GNU Coding Standards
@c This date is automagically updated when you save this file:
-@set lastupdate April 17, 1998
+@set lastupdate May 4, 1998
@c %**end of header
@ifinfo
With occasional exceptions, utility programs and libraries for GNU
should be upward compatible with those in Berkeley Unix, and upward
compatible with @sc{ansi} C if @sc{ansi} C specifies their behavior, and
-upward compatible with @sc{POSIX} if @sc{POSIX} specifies their
+upward compatible with @sc{posix} if @sc{posix} specifies their
behavior.
When these standards conflict, it is useful to offer compatibility
modes for each of them.
-@sc{ansi} C and @sc{POSIX} prohibit many kinds of extensions. Feel free
+@sc{ansi} C and @sc{posix} prohibit many kinds of extensions. Feel free
to make the extensions anyway, and include a @samp{--ansi},
@samp{--posix}, or @samp{--compatible} option to turn them off.
However, if the extension has a significant chance of breaking any real
programs or scripts, then it is not really upward compatible. Try to
redesign its interface.
-Many GNU programs suppress extensions that conflict with POSIX if the
+Many GNU programs suppress extensions that conflict with @sc{posix} if the
environment variable @code{POSIXLY_CORRECT} is defined (even if it is
defined with a null value). Please make your program recognize this
variable if appropriate.
in a directory, use @code{readdir} or some other high-level interface.
These will be supported compatibly by GNU.
-By default, the GNU system will provide the signal handling functions of
-@sc{BSD} and of @sc{POSIX}. So GNU software should be written to use
-these.
+The preferred signal handling facilities are the BSD variant of
+@code{signal}, andthe @sc{posix} @code{sigaction} function; the
+alternative USG @code{signal} interface is an inferior design.
+
+Nowadays, using the @sc{posix} signal functions may be the easiest way
+to make a program portable. If you use @code{signal}, then on GNU/Linux
+systems running GNU libc version 1, you should include
+@file{bsd/signal.h} instead of @file{signal.h}, so as to get BSD
+behavior. It is up to you whether to support systems where
+@code{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
like @code{ls} except that its default output format is always
multi-column format.
-It is a good idea to follow the @sc{POSIX} guidelines for the
+It is a good idea to follow the @sc{posix} guidelines for the
command-line options of a program. The easiest way to do this is to use
@code{getopt} to parse them. Note that the GNU version of @code{getopt}
will normally permit options anywhere among the arguments unless the
-special argument @samp{--} is used. This is not what @sc{POSIX}
+special argument @samp{--} is used. This is not what @sc{posix}
specifies; it is a GNU extension.
Please define long-named options that are equivalent to the
Make sure that no file name in the distribution is more than 14
characters long. Likewise, no file created by building the program
should have a name longer than 14 characters. The reason for this is
-that some systems adhere to a foolish interpretation of the POSIX
+that some systems adhere to a foolish interpretation of the @sc{posix}
standard, and refuse to open a longer name, rather than truncating as
they did in the past.
projects / thirdparty / autoconf.git / commitdiff
