[Cialug] Learning the 'C' language

[Morris Dovey]

Tad Anhalt wrote:

Good stuff - I just can't resist the temptation to amplify one some of
Tad's suggestions.

|    It looks like you've already received some valuable advice on
| how to start.  I'd like to add a few hard learned lessons that I
| wish I would have learned earlier.
|
|    I'll limit my comments as specific to the C language as possible
| because much more scope could result in a book.
|
|    Read the C FAQ:
| http://www.eskimo.com/~scs/C-faq/faq.html

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 news:comp.lang.c (CLC).

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
http://www.iedu.com/c provide important information about how to avoid
looking foolish on usenet in general and CLC specifically.

|    Do whatever it takes to learn what pointers are and how to use
|   them. Most C programmers haven't and it shows.

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.

|    Do whatever it takes to learn how to decode complicated
|   declarations. There are a few good tricks, Google knows.  K&R has
| a good section on it as well.

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.

|    Learn how the obfuscated and/or "efficient" and/or "mind blowing"
| code works, don't be tempted to use it in production code. Be aware
| that you will eventually see it in production code.  Probably late
| at night and in a debugger.  It'll probably be commented with
| something like "Don't change this code, you are incapable of
| understanding it."
|
|    Find the warning level switch on your compiler and crank it up to
| "11."  If there is a switch that allows warnings to be treated as
| errors, it's useful to use it as well.

Use of -ansi and -pedantic switches is also a good learning technique
(I've built these into my most-frequently used gcc makefile.)

|    Read the warnings produced.  This is where the "warnings as
| errors" switch comes in handy.
|
|    Understand the warnings.  Fix them if possible, put a comment in
| the code for ones that you can't.  Figure out how to disable
| specific warnings for your compiler - best case on a line-to-line
| basis, next best on a per-compilation unit basis, worst case lower
| the warning level as a last resort.
|
|    The idea is to keep the code in a state where there aren't pages
| upon pages of "expected" warnings streaming by that are hiding the
| ones you need to know about.  At the same time, you don't want to
| end up turning the warning level down to some useless level that
| doesn't tell you what you need to know.

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!

|    Find out if your compiler supports proprietary extensions.
| Prefer to turn them off.  Especially if they conflict with
| something in the standard.  Even gcc supports non-portable
| extensions.  Some of them are useful and there is nothing wrong
| with them, just know that they are non-standard and you may need to
| know how to do without at some point. Don't let it be when a
| deadline is looming or support is unexpectedly removed.
|
|    If your compiler supports multiple versions of the standard, set
| it to use the newest it knows about.  If it doesn't support the
| newest version, consider using a different one.  This isn't so much
| a problem for C, but C++ compilers have enormous differences in
| what they'll support at this point.
|
|    Don't be afraid to break out a C++ compiler and let it see what
| it thinks of your pristine C code.  Consider making it a habit.
|
|    If a function returns an error code, check it.  If you are making
| assumptions check them.  Be aware that most example code doesn't do
| either.

*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.

|    Be especially wary of code you don't control and/or don't
| understand.

Tough for a newbie - but it probably won't hurt to be just a bit
paranoid.


Morris Dovey
C links at http://www.iedu.com/c
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://cialug.org/pipermail/cialug/attachments/20051013/28d67f10/attachment-0001.html