| From: nils <nils at eircom.net>
| Date: Sun, 14 Mar 2004 02:32:35 +0000
| 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
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
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.
«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
Maintained by the ILUG website team. The aim of Linux.ie is to
support and help commercial and private users of Linux in Ireland. You can
display ILUG news in your own webpages, read backend
information to find out how. Networking services kindly provided by HEAnet, server kindly donated by
Dell. Linux is a trademark of Linus Torvalds,
used with permission. No penguins were harmed in the production or maintenance
of this highly praised website. Looking for the
Indian Linux Users' Group? Try here. If you've read all this and aren't a lawyer: you should be!