From: Richard M. Stallman Date: Mon, 18 May 1998 04:38:44 +0000 (+0000) Subject: Clarify discussion of signal interfaces. X-Git-Tag: fsf-origin~12 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=3bace3884c564866be546fdf9748e96b3138ccbf;p=thirdparty%2Fautoconf.git Clarify discussion of signal interfaces. Write POSIX uniformly. --- diff --git a/doc/standards.texi b/doc/standards.texi index 145e10b3..aff7ced6 100644 --- a/doc/standards.texi +++ b/doc/standards.texi @@ -3,7 +3,7 @@ @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 @@ -219,20 +219,20 @@ account when designing your program. 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. @@ -430,9 +430,16 @@ are less likely to work compatibly. If you need to find all the files 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 @@ -552,11 +559,11 @@ output device type. For example, we provide a @code{dir} program much 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 @@ -3056,7 +3063,7 @@ Make sure that all the files in the distribution are world-readable. 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. diff --git a/standards.texi b/standards.texi index 145e10b3..aff7ced6 100644 --- a/standards.texi +++ b/standards.texi @@ -3,7 +3,7 @@ @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 @@ -219,20 +219,20 @@ account when designing your program. 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. @@ -430,9 +430,16 @@ are less likely to work compatibly. If you need to find all the files 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 @@ -552,11 +559,11 @@ output device type. For example, we provide a @code{dir} program much 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 @@ -3056,7 +3063,7 @@ Make sure that all the files in the distribution are world-readable. 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.