> -----Original Message-----
> From: piclist-bounces@mit.edu On Behalf Of Jason Hsu
> Sent: Sunday, February 07, 2010 11:17 PM
>
> Paul, thanks for the #pragma suggestion.  Splint no longer gives me an
> error message for the "__CONFIG" line when I start it off with
> "#pragma __CONFIG xxx".
>
> However, splint now refuses to recognize the variables that were
> declared in the *.h files #included at the beginning of the program.
>
> Is using splint a lost cause for embedded engineering?  Was it meant
> for stand-alone computer programs?  I thought it would help me write
> better code, but it's of no value if it ends up just getting in the
> way instead, especially if it only reports the first error it finds
> and then ignores the rest of the program.

Using Splint is a lot of work for C's on small microcontrollers and may not
be worth the effort for you. Commercial lints are a better choice for many
people, especially if you choose one that already provides configuration
files for the particular C compiler you are using.

IMO, there are a few things to adopt that give more bang for the buck before
adding a lint to your workflow.

1. Turn up all warning/error levels on the compiler to the highest level
then adjust your coding style to stop the errors and warnings. I've
generally found that once I dig deeply into why a compiler generates a
warning, I realize how useful re-coding to prevent the warnings is for
avoiding problems.

2. Have a formal coding conventions document for your organization and
follow it strictly. Don't forget to update the document over time to include
any better techniques you discover.

3. Work towards the absolute highest compatibility with plain portable ANSI
C. Force yourself to make a case for any compiler specific extension use and
put them in your coding conventions document.

These steps are likely going to force you to type a lot more C code but IME
they won't significantly change the size of the compiler output. Once you
get to this point then adding a lint to the workflow can help to further
bulletproof your code.

The products I generally work on are for customers that expect to power up
the device and have it run continuously for 10 years without a required
reboot. With this demanding of a customer base it pays us to use every
possible technique to avoid problems.

Paul Hutch

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist