gnustandards-commit
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

gnustandards ChangeLog standards.texi


From: Karl Berry
Subject: gnustandards ChangeLog standards.texi
Date: Thu, 09 Sep 2010 21:59:42 +0000

CVSROOT:        /sources/gnustandards
Module name:    gnustandards
Changes by:     Karl Berry <karl>       10/09/09 21:59:42

Modified files:
        .              : ChangeLog standards.texi 

Log message:
        more analysis tools there is no need to obfuscate code in order to 
placate, from Paul Eggert

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/gnustandards/ChangeLog?cvsroot=gnustandards&r1=1.121&r2=1.122
http://cvs.savannah.gnu.org/viewcvs/gnustandards/standards.texi?cvsroot=gnustandards&r1=1.199&r2=1.200

Patches:
Index: ChangeLog
===================================================================
RCS file: /sources/gnustandards/gnustandards/ChangeLog,v
retrieving revision 1.121
retrieving revision 1.122
diff -u -b -r1.121 -r1.122
--- ChangeLog   25 Aug 2010 00:07:21 -0000      1.121
+++ ChangeLog   9 Sep 2010 21:59:42 -0000       1.122
@@ -1,3 +1,8 @@
+2010-09-09  Paul Eggert  <address@hidden>
+
+       * standards.texi (Memory Usage): mention no need to placate valgrind.
+       (Syntactic Conventions): mention no need to placate lint/clang/etc.
+
 2010-08-24  Karl Berry  <address@hidden>
 
        * make-stds.texi (Standard Targets): parenthetical instead of

Index: standards.texi
===================================================================
RCS file: /sources/gnustandards/gnustandards/standards.texi,v
retrieving revision 1.199
retrieving revision 1.200
diff -u -b -r1.199 -r1.200
--- standards.texi      25 Aug 2010 00:07:21 -0000      1.199
+++ standards.texi      9 Sep 2010 21:59:42 -0000       1.200
@@ -2322,6 +2322,13 @@
 If your program creates complicated data structures, just make them in
 memory and give a fatal error if @code{malloc} returns zero.
 
address@hidden valgrind
address@hidden memory leak
+Memory leak detectors such as @command{valgrind} can be useful, but
+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.
+
 @node File Usage
 @section File Usage
 @cindex file usage
@@ -2630,6 +2637,17 @@
 If you want to do this, then do.  The compiler should be your servant,
 not your master.
 
address@hidden clang
address@hidden lint
+Don't make the program ugly just to placate static analysis tools such
+as @command{lint}, @command{clang}, and GCC with extra warnings
+options such as @option{-Wconversion} and @option{-Wundef}.  These
+tools can help find bugs and unclear code, but they can also generate
+so many false alarms that that it hurts readability to silence them
+with unnecessary casts, wrappers, and other complications.  For
+example, please don't insert casts to @code{void} or calls to
+do-nothing functions merely to pacify a lint checker.
+
 Declarations of external functions and functions to appear later in the
 source file should all go in one place near the beginning of the file
 (somewhere before the first function definition in the file), or else
@@ -2647,6 +2665,7 @@
 all its uses.  This makes the program even cleaner.
 
 Don't use local variables or parameters that shadow global identifiers.
+GCC's @samp{-Wshadow} option can detect this problem.
 
 @cindex multiple variables in a line
 Don't declare multiple variables in one declaration that spans lines.
@@ -2750,10 +2769,9 @@
   fatal ("virtual memory exhausted");
 @end example
 
address@hidden lint
-Don't make the program ugly to placate @code{lint}.  Please don't insert any
-casts to @code{void}.  Zero without a cast is perfectly fine as a null
-pointer constant, except when calling a varargs function.
+This example uses zero without a cast as a null pointer constant.
+This is perfectly fine, except that a cast is needed when calling a
+varargs function or when using @code{sizeof}.
 
 @node Names
 @section Naming Variables, Functions, and Files



reply via email to

[Prev in Thread] Current Thread [Next in Thread]