*** standards.texi	2024-07-28 13:02:16.184366797 -0700
--- standards.texi-c99	2024-10-13 21:49:21.727622568 -0700
***************
*** 3,9 ****
  @setfilename standards.info
  @settitle GNU Coding Standards
  @c This date is automagically updated when you save this file:
! @set lastupdate May 26, 2024
  @c %**end of header
  
  @dircategory GNU organization
--- 3,9 ----
  @setfilename standards.info
  @settitle GNU Coding Standards
  @c This date is automagically updated when you save this file:
! @set lastupdate October 13, 2024
  @c %**end of header
  
  @dircategory GNU organization
***************
*** 390,405 ****
  already.  That would be extremely troublesome in certain cases.
  
  @node Standard C
! @section Standard C and Pre-Standard C
  @cindex 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
! ``trigraph'' feature of Standard C.
  
! The 1999 and 2011 editions of Standard C are not fully supported
  on all platforms.  If you aim to support compilation by
! compilers other than GCC, you should not require these C
  features in your programs.  It is ok to use these features
  conditionally when the compiler supports them.
  
--- 390,408 ----
  already.  That would be extremely troublesome in certain cases.
  
  @node Standard C
! @section Standard C
  @cindex ANSI C standard
  
! C99 is widespread enough now that it is ok to use its features in
! programs, with two main exceptions.  First, do not ever use the
! ``trigraph'' misfeature introduced by C89 and not removed until C23.
! Second, because C11 no longer requires support for variable length
! arrays, it is often better to use this C99 feature only if it is
! available.
  
! Not all features of recent Standard C are fully supported
  on all platforms.  If you aim to support compilation by
! compilers other than GCC, you should not require newer Standard C
  features in your programs.  It is ok to use these features
  conditionally when the compiler supports them.
  
***************
*** 407,427 ****
  use these features if GCC supports them, when they give substantial
  benefit.
  
! However, it is easy to support pre-standard compilers in most programs,
  so if you know how to do that, feel free.
  
  @cindex function prototypes
! To support pre-standard C, instead of writing function definitions in
! standard prototype form,
! 
! @example
! int
! foo (int x, int y)
! @dots{}
! @end example
! 
! @noindent
! write the definition in pre-standard style like this,
  
  @example
  int
--- 410,420 ----
  use these features if GCC supports them, when they give substantial
  benefit.
  
! However, it is easy to support nonstandard compilers in most programs,
  so if you know how to do that, feel free.
  
  @cindex function prototypes
! Before C89, functions needed to be written in a style like this:
  
  @example
  int
***************
*** 431,471 ****
  @end example
  
  @noindent
! and use a separate declaration to specify the argument prototype:
  
  @example
! int foo (int, int);
! @end example
! 
! You need such a declaration anyway, in a header file, to get the benefit
! of prototypes in all the files where the function is called.  And once
! you have the declaration, you normally lose nothing by writing the
! function definition in the pre-standard style.
! 
! This technique does not work for integer types narrower than @code{int}.
! If you think of an argument as being of a type narrower than @code{int},
! declare it as @code{int} instead.
! 
! There are a few special cases where this technique is hard to use.  For
! example, if a function argument needs to hold the system type
! @code{dev_t}, you run into trouble, because @code{dev_t} is shorter than
! @code{int} on some machines; but you cannot use @code{int} instead,
! because @code{dev_t} is wider than @code{int} on some machines.  There
! is no type you can safely use on all machines in a non-standard
! definition.  The only way to support non-standard C and pass such an
! argument is to check the width of @code{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:
! 
! @example
! /* Declare the prototype for a general external function.  */
! #if defined (__STDC__) || defined (WINDOWSNT)
! #define P_(proto) proto
! #else
! #define P_(proto) ()
! #endif
  @end example
  
  @node Conditional Compilation
--- 424,436 ----
  @end example
  
  @noindent
! C23 no longer requires support for this obsolescent style,
! and you should use function prototypes instead:
  
  @example
! int
! foo (int x, int y)
! @dots{}
  @end example
  
  @node Conditional Compilation
***************
*** 557,563 ****
  portably.  For instance, GCC implements nearly all the features of
  Standard C as specified by that standard.  C program developers would
  be unhappy if it did not.  And GNU utilities mostly follow
! specifications of POSIX.2; shell script writers and users would be
  unhappy if our programs were incompatible.
  
  But we do not follow either of these specifications rigidly, and there
--- 522,528 ----
  portably.  For instance, GCC implements nearly all the features of
  Standard C as specified by that standard.  C program developers would
  be unhappy if it did not.  And GNU utilities mostly follow
! specifications of POSIX; shell script writers and users would be
  unhappy if our programs were incompatible.
  
  But we do not follow either of these specifications rigidly, and there
***************
*** 572,586 ****
  we can say ``GCC is a 100% implementation of the standard'', not
  because there is any reason to actually use it.
  
! POSIX.2 specifies that @samp{df} and @samp{du} must output sizes by
  default in units of 512 bytes.  What users want is units of 1k, so
  that is what we do by default.  If you want the ridiculous behavior
  ``required'' by POSIX, you must set the environment variable
  @samp{POSIXLY_CORRECT} (which was originally going to be named
  @samp{POSIX_ME_HARDER}).
  
! GNU utilities also depart from the letter of the POSIX.2 specification
! when they support long-named command-line options, and intermixing
  options with ordinary arguments.  This minor incompatibility with
  POSIX is never a problem in practice, and it is very useful.
  
--- 537,551 ----
  we can say ``GCC is a 100% implementation of the standard'', not
  because there is any reason to actually use it.
  
! POSIX specifies that @samp{df} and @samp{du} must output sizes by
  default in units of 512 bytes.  What users want is units of 1k, so
  that is what we do by default.  If you want the ridiculous behavior
  ``required'' by POSIX, you must set the environment variable
  @samp{POSIXLY_CORRECT} (which was originally going to be named
  @samp{POSIX_ME_HARDER}).
  
! GNU utilities also depart from the letter of the POSIX specification
! when they support intermixing
  options with ordinary arguments.  This minor incompatibility with
  POSIX is never a problem in practice, and it is very useful.
  
***************
*** 2474,2480 ****
  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:
  
  @example
  static char *
--- 2439,2445 ----
  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 C syntax, the format is this:
  
  @example
  static char *
***************
*** 2484,2503 ****
  @}
  @end example
  
! @noindent
! or, if you want to use traditional C syntax, format the definition like
! this:
! 
! @example
! static char *
! concat (s1, s2)        /* Name starts in column one here */
!      char *s1, *s2;
! @{                     /* Open brace in column one here */
!   @dots{}
! @}
! @end example
! 
! In Standard C, if the arguments don't fit nicely on one line,
  split it like this:
  
  @example
--- 2449,2455 ----
  @}
  @end example
  
! If the arguments don't fit nicely on one line,
  split it like this:
  
  @example
***************
*** 3082,3090 ****
  
  Historically, C implementations differed substantially, and many
  systems lacked a full implementation of ANSI/ISO C89.  Nowadays,
! however, all practical systems have a C89 compiler and GNU C supports
! almost all of C99 and some of C11.  Similarly, most systems implement
! POSIX.1-2001 libraries and tools, and many have POSIX.1-2008.
  
  Hence, there is little reason to support old C or non-POSIX systems,
  and you may want to take advantage of standard C and POSIX to write
--- 3034,3042 ----
  
  Historically, C implementations differed substantially, and many
  systems lacked a full implementation of ANSI/ISO C89.  Nowadays,
! however, all practical systems have a C89-or-later compiler and
! GNU C supports almost all of C23.  Similarly, most systems implement
! POSIX.1-2008 libraries and tools, and many have POSIX.1-2017.
  
  Hence, there is little reason to support old C or non-POSIX systems,
  and you may want to take advantage of standard C and POSIX to write
***************
*** 3118,3124 ****
  this regard.  Gnulib provides implementations of standard interfaces
  on many of the systems that lack them, including portable
  implementations of enhanced GNU interfaces, thereby making their use
! portable, and of POSIX-1.2008 interfaces, some of which are missing
  even on up-to-date GNU systems.
  
  @findex xmalloc, in Gnulib
--- 3070,3076 ----
  this regard.  Gnulib provides implementations of standard interfaces
  on many of the systems that lack them, including portable
  implementations of enhanced GNU interfaces, thereby making their use
! portable, and of POSIX interfaces, some of which are missing
  even on up-to-date GNU systems.
  
  @findex xmalloc, in Gnulib
***************
*** 3126,3132 ****
  @findex data structures, in Gnulib
  Gnulib also provides many useful non-standard interfaces; for example,
  C implementations of standard data structures (hash tables, binary
! trees), error-checking type-safe wrappers for memory allocation
  functions (@code{xmalloc}, @code{xrealloc}), and output of error
  messages.
  
--- 3078,3084 ----
  @findex data structures, in Gnulib
  Gnulib also provides many useful non-standard interfaces; for example,
  C implementations of standard data structures (hash tables, binary
! trees), error-checking wrappers for memory allocation
  functions (@code{xmalloc}, @code{xrealloc}), and output of error
  messages.