[ILUG] C being poliltically correct.

[Brian Foster]

  | From: nils <nils at eircom.net>
  | Date: Sun, 14 Mar 2004 02:32:35 +0000
  | 
  | hi,
  | Learning C/C++ can be quite danting to anyone....

 I do hope you realize C and C++ are different languages.

  |[ warning from strcpy(3) man(1) page about buffer overflows,
  |  but which rather noticeably forgets to warn about the most
  |  common mistake, neglecting to including the terminal nul
  |  (\0) in the destination size calculations ]
  | 
  | Is there a list of ways to make sure that you are doing the
  | correct thing when it comes to writing C/C++ i.e as the above
  | points out, or is it just trial and error.  You can figure
  | out the simple thing about C/C++ but when it come to more
  | complex stuff and learning bad habbits can be a pain and
  | costly, anyone any idea on what book/website i might look at.

 as others have said, please use <Return> every c.70 characters
 or so; and w.r.t. yer question, common sense plus experience
 helps ....

 yes, there are assorted lists out there, albeit I suspect
 most of them tend to be presented in the guise of other
 issues, such as the maintainability or portability of the
 source code, or defensive programming, or security, or
 program correctness, &tc ....  some are quite detailed and
 long, whilst others (Henry Spencer's “Ten Commandments of
 C Programming" comes to mind here) are concise.  (apologies,
 I don't have any URLs at hand; google™ is yer friend here.)

 there are also tools to aid correctness and testing (which
 is closely related).  all(?) that I know of (and use!) are
 after-the-fact tools; i.e., they check you have written,
 not help/guide/force you to write it better in the first
 place.  three I would look into, in this order, are first
 off splint(1) --- mentioned as the generic “lint‟ in Henry
 Spencer's Commandments --- then valgrind(1), then gcov(1).

 `splint' for spotting issues in the source before you
 compile it (albeit C only, no C++); various gcc(1) flags
 (e.g., `-Wall -pedantic' and others) for spotting issues
 as you compile it; `valgrind' for spotting errors in the
 code as it runs; and `gcov' for insuring all the code has
 actually been run (tested).

 I also suggest you make friends with assert(3), and use it
 liberally.  (and also with several C/C++ language features,
 such as the <const>-qualifier.)  e.g., for the strcpy(3)
 issue (please note the following assumes the size in bytes
 of the destination is known, and that the input source is
 properly nul-terminated!):

     char *src;
     char  dest[N];
       ...
     assert(src != (char *)0);               // cannot copy NULL
     assert(strlen(src)+1 <= sizeof(dest));  // +1 for nul (\0)
     (void) strcpy(dest, src);

 and, w.r.t. again to strcpy(), please note strncpy(3) is
 not at all equivalent, whilst you won't overflow the
 destination buffer (assuming the size passed to strncpy()
 is correct), the copied result may not be nul-terminated
 (the usual error when using strncpy()); or may be terminated
 by multiple nuls (usually not an issue, but does preclude
 straight-forward replacement in some cases).

 whilst not directly related to yer question, in terms of
 learning good habits, you may wish to write documented
 code; so check out doxygen(1).  (user documentation, e.g.
 man(1) pages, is another issue altogether.)

 hope this helps.  sorry for the lack of URLs.
cheers!
	-blf-
-- 
«How many surrealists does it take to    |  Brian Foster      Montpellier,
 change a lightbulb?  Three.  One calms  |  blf at utvinternet.ie      France
 the warthog, and two fill the bathtub   |    Stop E$$o (ExxonMobile)!
 with brightly-colored machine tools.»   |        http://www.stopesso.com