As requested by Alfred Szmidt.
---------- Forwarded message ----------
From: Reuben Thomas <[email protected]>
Date: 25 April 2011 16:20
Subject: Patch to GCS
To: Karl Berry <[email protected]>
There's a heck of a lot more I could do, but relatively brief as my
edits so far are, I suspect they may need quite a lot of
consideration, so I attach a patch of where I'm up to.
Given that pretty much every extant platform has a Standard C
compiler, and that many GNU programs have already dropped support for
K&R C, is it not time to remove the advice about how to keep programs
pre-standard-compatible? Then we could move on to update the guidance
for use of C89 vs C99: a pretty accurate summary is that C99 is now to
C89 as C89 was to K&R when the advice was originally written: i.e.,
it's simple and worthwhile to keep C89-compatibility in existing code,
but (with a few exceptions) C99 support is widespread and can be used
to improve new code.
--
http://rrt.sc3d.org
? standards.texi.diff
Index: standards.texi
===================================================================
RCS file: /sources/gnustandards/gnustandards/standards.texi,v
retrieving revision 1.203
diff -u -r1.203 standards.texi
--- standards.texi 28 Mar 2011 22:56:55 -0000 1.203
+++ standards.texi 25 Apr 2011 14:20:20 -0000
@@ -3,7 +3,7 @@
@setfilename standards.info
@settitle GNU Coding Standards
@c This date is automagically updated when you save this file:
-@set lastupdate March 28, 2011
+@set lastupdate April 25, 2011
@c %**end of header
@dircategory GNU organization
@@ -225,8 +225,7 @@
We have more detailed advice for maintainers of programs; if you have
reached the stage of actually maintaining a program for GNU (whether
-released or not), please ask us for a copy. It is also available
-online for your perusal: @uref{http://www.gnu.org/prep/maintain/}.
+released or not), read it at: @uref{http://www.gnu.org/prep/maintain/}.
@node Trademarks
@section Trademarks
@@ -581,10 +580,9 @@
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
+that is what we do by default. If you really want the behavior
``required'' by POSIX, you must set the environment variable
-@samp{POSIXLY_CORRECT} (which was originally going to be named
-@samp{POSIX_ME_HARDER}).
+@samp{POSIXLY_CORRECT}.
GNU utilities also depart from the letter of the POSIX.2 specification
when they support long-named command-line options, and intermixing
@@ -605,17 +603,13 @@
@cindex @code{NUL} characters
Utilities reading files should not drop NUL characters, or any other
-nonprinting characters @emph{including those with codes above 0177}.
-The only sensible exceptions would be utilities specifically intended
-for interface to certain types of terminals or printers
-that can't handle those characters.
-Whenever possible, try to make programs work properly with
-sequences of bytes that represent multibyte characters, using encodings
-such as UTF-8 and others.
+nonprinting characters.
+Programs should work properly with multibyte character encodings, such
+as UTF-8. You can use libiconv to deal with a wide range of encodings.
@cindex error messages
Check every system call for an error return, unless you know you wish to
-ignore errors. Include the system error text (from @code{perror} or
+ignore errors. Include the system error text (from @code{strerror} or
equivalent) in @emph{every} error message resulting from a failing
system call, as well as the name of the file if any and the name of the
utility. Just ``cannot open foo.c'' or ``stat failed'' is not
@@ -624,16 +618,10 @@
@cindex @code{malloc} return value
@cindex memory allocation failure
Check every call to @code{malloc} or @code{realloc} to see if it
-returned zero. Check @code{realloc} even if you are making the block
-smaller; in a system that rounds block sizes to a power of 2,
+returned @code{NULL}. Check @code{realloc} even if you are making the
+block smaller; in a system that rounds block sizes to a power of 2,
@code{realloc} may get a different block if you ask for less space.
-In Unix, @code{realloc} can destroy the storage block if it returns
-zero. GNU @code{realloc} does not have this bug: if it fails, the
-original block is unchanged. Feel free to assume the bug is fixed. If
-you wish to run your program on Unix, and wish to avoid lossage in this
-case, you can use the GNU @code{malloc}.
-
You must expect @code{free} to alter the contents of the block that was
freed. Anything you want to fetch from the block, you must fetch before
calling @code{free}.
@@ -651,7 +639,7 @@
When static storage is to be written in during program execution, use
explicit C code to initialize it. Reserve C initialized declarations
for data that will not be changed.
-@c ADR: why?
+@c ADR: why? <-- Why indeed? Justify or remove?
Try to avoid low-level interfaces to obscure Unix data structures (such
as file directories, utmp, or the layout of kernel memory), since these
@@ -2333,6 +2321,9 @@
don't complicate a program merely to avoid their false alarms. For
example, if memory is used until just before a process exits, don't
free it simply to silence a leak detector.
+@c RRT: This is a bad example, as it’s not a leak, and valgrind wouldn’t
+@c complain about it (merely report that the memory was still in use and
+@c reachable).
@node File Usage
@section File Usage
