<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 5.50.4134.600" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV>Tad Anhalt wrote:<BR></DIV>
<DIV><FONT size=2>Good stuff - I just can't resist the temptation to amplify one
some of Tad's suggestions.</FONT><BR></DIV>
<DIV>| It looks like you've already received some valuable
advice on<BR>| how to start. I'd like to add a few hard learned lessons
that I<BR>| wish I would have learned earlier.<BR>| <BR>| I'll
limit my comments as specific to the C language as possible<BR>| because much
more scope could result in a book.<BR>| <BR>| Read the C
FAQ:<BR>| <A
href="http://www.eskimo.com/~scs/C-faq/faq.html">http://www.eskimo.com/~scs/C-faq/faq.html</A></DIV>
<DIV> </DIV>
<DIV><FONT size=2>Yes! Steve knows his stuff and this FAQ has been peer-reviewed
by the best of the best C programmers in the world. It's a compendium of the
frequently asked questions posted to <A
href="news:comp.lang.c">news:comp.lang.c</A> (CLC).</FONT></DIV>
<DIV><FONT size=2></FONT> </DIV>
<DIV><FONT size=2>Once you've read the FAQ, CLC is one of the best places I know
of to get answers to really tough questions. BTW, the first five links at <A
href="http://www.iedu.com/c">http://www.iedu.com/c</A> provide important
information about how to avoid looking foolish on usenet in general and CLC
specifically.</FONT></DIV>
<DIV><BR>| Do whatever it takes to learn what pointers are and
how to use<BR>| them. Most C programmers haven't and it shows.</DIV>
<DIV> </DIV>
<DIV><FONT size=2>So right! I have an ever-stronger suspicion that this is the
cause of most of the security holes in MS software. Pointer manipulation is one
of C's greatest strengths and, when misused, a major source of
problems.</FONT></DIV>
<DIV><FONT size=2></FONT> </DIV>
<DIV>| Do whatever it takes to learn how to decode
complicated<BR>| declarations. There are a few good tricks, Google
knows. K&R has<BR>| a good section on it as well.</DIV>
<DIV> </DIV>
<DIV><FONT size=2>There's also a utility that'll do that decode and provide a
prose translation. IIRC, it'll also help construct the (occasionally necessary)
hairball declarations. I haven't used it for so long that I've forgotten its
name - but it should show up in an apropos query.</FONT></DIV>
<DIV><FONT size=2></FONT> </DIV>
<DIV>| Learn how the obfuscated and/or "efficient" and/or
"mind blowing"<BR>| code works, don't be tempted to use it in production code.
Be aware<BR>| that you will eventually see it in production code. Probably
late<BR>| at night and in a debugger. It'll probably be commented
with<BR>| something like "Don't change this code, you are incapable of<BR>|
understanding it." <BR>| <BR>| Find the warning level switch
on your compiler and crank it up to<BR>| "11." If there is a switch that
allows warnings to be treated as<BR>| errors, it's useful to use it as
well.</DIV>
<DIV> </DIV>
<DIV><FONT size=2>Use of -ansi and -pedantic switches is also a good learning
technique (I've built these into my most-frequently used gcc
makefile.)</FONT><BR></DIV>
<DIV>| Read the warnings produced. This is where the
"warnings as<BR>| errors" switch comes in handy.<BR>| <BR>|
Understand the warnings. Fix them if possible, put a comment in<BR>| the
code for ones that you can't. Figure out how to disable<BR>| specific
warnings for your compiler - best case on a line-to-line<BR>| basis, next best
on a per-compilation unit basis, worst case lower<BR>| the warning level as a
last resort.<BR>| <BR>| The idea is to keep the code in a
state where there aren't pages<BR>| upon pages of "expected" warnings streaming
by that are hiding the<BR>| ones you need to know about. At the same time,
you don't want to<BR>| end up turning the warning level down to some useless
level that<BR>| doesn't tell you what you need to know.</DIV>
<DIV> </DIV>
<DIV><FONT size=2>Turn warning sensitivity up as high as it'll go and clean the
code until it'll compile without even a single warning! If you don't have a copy
of the lint utility, download and use it!</FONT></DIV>
<DIV><FONT size=2></FONT> </DIV>
<DIV>| Find out if your compiler supports proprietary
extensions. <BR>| Prefer to turn them off. Especially if they conflict
with<BR>| something in the standard. Even gcc supports non-portable<BR>|
extensions. Some of them are useful and there is nothing wrong<BR>| with
them, just know that they are non-standard and you may need to<BR>| know how to
do without at some point. Don't let it be when a<BR>| deadline is looming or
support is unexpectedly removed.<BR>| <BR>| If your compiler
supports multiple versions of the standard, set<BR>| it to use the newest it
knows about. If it doesn't support the<BR>| newest version, consider using
a different one. This isn't so much<BR>| a problem for C, but C++
compilers have enormous differences in<BR>| what they'll support at this
point.<BR>| <BR>| Don't be afraid to break out a C++ compiler
and let it see what<BR>| it thinks of your pristine C code. Consider
making it a habit.<BR>| <BR>| If a function returns an error
code, check it. If you are making<BR>| assumptions check them. Be
aware that most example code doesn't do<BR>| either.</DIV>
<DIV> </DIV>
<DIV><FONT size=2>*YES!* Failing to check for every detectable error condition
is just plain irresponsible and allows small, correctable/recoverable runtime
errors to escalate into system crashers.</FONT></DIV>
<DIV><FONT size=2></FONT> </DIV>
<DIV>| Be especially wary of code you don't control and/or
don't<BR>| understand. </DIV>
<DIV> </DIV>
<DIV><FONT size=2>Tough for a newbie - but it probably won't hurt to be just a
bit paranoid.</FONT><BR></DIV>
<DIV><FONT size=2></FONT><BR>Morris Dovey<BR>C links at <A
href="http://www.iedu.com/c">http://www.iedu.com/c</A></DIV></BODY></HTML>