Here's a proposed patch to standards.texi, to better reflect current
practice in GNU hacking, and to reflect newer versions of C and POSIX
standards.
The main change is to say that it's OK to assume C99, except for VLAs.
Many (most?) GNU programs are doing this already, e.g., by using
declarations after statements.
This patch also drops coverage of the K&R function definition style, as
this is no longer needed on practical platforms and C23 no longer
requires support for that syntax.
Also, C23 removed trigraphs (finally!).
There is no longer a "POSIX.2"; it's just POSIX.1.
Long options like --help are not prohibited by POSIX, as far as I can
see. Perhaps old POSIX prohibited them, but that ship sailed long ago,
they're now universal, and I don't see POSIX prohibiting them now.diff --git a/doc/standards.texi b/doc/standards.texi
index b1562b93..0e94ca51 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 August 17, 2021
+@set lastupdate April 30, 2024
@c %**end of header
@dircategory GNU organization
@@ -393,13 +393,16 @@ already. That would be extremely troublesome in certain cases.
@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.
+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.
-The 1999 and 2011 editions of Standard C are not fully supported
+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 these C
+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,21 +410,11 @@ If your program is only meant to compile with GCC, then you can
use these features if GCC supports them, when they give substantial
benefit.
-However, it is easy to support pre-standard compilers in most programs,
+However, it is easy to support nonstandard 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,
+Before C89, functions needed to be written in pre-standard style like this:
@example
int
@@ -431,41 +424,13 @@ foo (x, y)
@end example
@noindent
-and use a separate declaration to specify the argument prototype:
+C23 no longer requires support for this obsolescent style,
+and you should use function prototypes instead:
@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
+int
+foo (int x, int y)
+@dots{}
@end example
@node Conditional Compilation
@@ -557,7 +522,7 @@ users---it means that their programs or scripts will work more
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
+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,15 +537,15 @@ you must specify @samp{--pedantic}, which was implemented only so that
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
+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.2 specification
-when they support long-named command-line options, and intermixing
+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,7 +2439,7 @@ if you find it useful to treat that definition as a defun.
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:
+using C syntax, the format is this:
@example
static char *
@@ -2484,20 +2449,7 @@ concat (char *s1, char *s2)
@}
@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,
+If the arguments don't fit nicely on one line,
split it like this:
@example
@@ -3082,9 +3034,9 @@ from zero.
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.
+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,7 +3070,7 @@ On Windows, @code{errno} is not set on failure.
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
+portable, and of POSIX interfaces, some of which are missing
even on up-to-date GNU systems.
@findex xmalloc, in Gnulib
@@ -3126,7 +3078,7 @@ even on up-to-date GNU systems.
@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
+trees), error-checking wrappers for memory allocation
functions (@code{xmalloc}, @code{xrealloc}), and output of error
messages.
