gnustandards ChangeLog standards.texi

[karl]

CVSROOT:        /sources/gnustandards
Module name:    gnustandards
Changes by:     karl <karl>     13/01/01 23:59:59

Modified files:
        .              : ChangeLog standards.texi 

Log message:
        avoid @sc

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/gnustandards/ChangeLog?cvsroot=gnustandards&r1=1.173&r2=1.174
http://cvs.savannah.gnu.org/viewcvs/gnustandards/standards.texi?cvsroot=gnustandards&r1=1.222&r2=1.223

Patches:
Index: ChangeLog
===================================================================
RCS file: /sources/gnustandards/gnustandards/ChangeLog,v
retrieving revision 1.173
retrieving revision 1.174
diff -u -b -r1.173 -r1.174
--- ChangeLog   1 Jan 2013 23:57:55 -0000       1.173
+++ ChangeLog   1 Jan 2013 23:59:59 -0000       1.174
@@ -1,3 +1,8 @@
+2013-01-01  Karl Berry  <address@hidden>
+
+       * standards.texi: do not use @sc, for consistency
+       with other manuals.
+
 2013-01-01  Paul Eggert  <address@hidden>
        and Richard Stallman  <address@hidden>
 

Index: standards.texi
===================================================================
RCS file: /sources/gnustandards/gnustandards/standards.texi,v
retrieving revision 1.222
retrieving revision 1.223
diff -u -b -r1.222 -r1.223
--- standards.texi      1 Jan 2013 23:57:55 -0000       1.222
+++ standards.texi      1 Jan 2013 23:59:59 -0000       1.223
@@ -339,20 +339,21 @@
 
 @node Compatibility
 @section Compatibility with Other Implementations
address@hidden compatibility with C and @sc{posix} standards
address@hidden @sc{posix} compatibility
address@hidden compatibility with C and POSIX standards
address@hidden C compatibility
address@hidden POSIX compatibility
 
 With occasional exceptions, utility programs and libraries for GNU
 should be upward compatible with those in Berkeley Unix, and upward
 compatible with Standard C if Standard C specifies their
-behavior, and upward compatible with @sc{posix} if @sc{posix} specifies
+behavior, and upward compatible with POSIX if POSIX specifies
 their behavior.
 
 When these standards conflict, it is useful to offer compatibility
 modes for each of them.
 
 @cindex options for compatibility
-Standard C and @sc{posix} prohibit many kinds of extensions.  Feel
+Standard C and 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
@@ -360,7 +361,7 @@
 should try to redesign its interface to make it upward compatible.
 
 @cindex @code{POSIXLY_CORRECT}, environment variable
-Many GNU programs suppress extensions that conflict with @sc{posix} if the
+Many GNU programs suppress extensions that conflict with 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.
@@ -408,7 +409,7 @@
 
 @node Standard C
 @section Standard C and Pre-Standard C
address@hidden @sc{ansi} C standard
address@hidden ANSI C standard
 
 1989 Standard C is widespread enough now that it is ok to use its
 features in programs.  There is one exception: do not ever use the
@@ -670,10 +671,10 @@
 
 @cindex signal handling
 The preferred signal handling facilities are the BSD variant of
address@hidden, and the @sc{posix} @code{sigaction} function; the
address@hidden, and the 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
+Nowadays, using the 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
@@ -906,11 +907,11 @@
 @cindex command-line interface
 
 @findex getopt
-It is a good idea to follow the @sc{posix} guidelines for the
+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
 @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 POSIX
 specifies; it is a GNU extension.
 
 @cindex long-named options
@@ -2871,7 +2872,7 @@
 not paramount.
 
 The primary purpose of GNU software is to run on top of the GNU kernel,
-compiled with the GNU C compiler, on various types of @sc{cpu}.  So the
+compiled with the GNU C compiler, on various types of CPU.  So the
 kinds of portability that are absolutely necessary are quite limited.
 But it is important to support Linux-based GNU systems, since they
 are the form of GNU that is popular.
@@ -2893,7 +2894,7 @@
 Avoid using the format of semi-internal data bases (e.g., directories)
 when there is a higher-level alternative (@code{readdir}).
 
address@hidden address@hidden systems, and portability
address@hidden non-POSIX systems, and portability
 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
@@ -2922,11 +2923,11 @@
 to move your code into other GNU programs.
 
 @node CPU Portability
address@hidden Portability between @sc{cpu}s
address@hidden Portability between CPUs
 
 @cindex data types, and portability
 @cindex portability, and data types
-Even GNU systems will differ because of differences among @sc{cpu}
+Even GNU systems will differ because of differences among CPU
 types---for example, difference in byte ordering and alignment
 requirements.  It is absolutely essential to handle these differences.
 However, don't make any effort to cater to the possibility that an