> -----Original Message----- > From: piclist-bounces@mit.edu On Behalf Of Gerhard Fiedler > Sent: Saturday, December 18, 2004 7:56 AM > How are you handling this issue? See my answer after my next comment. > > Next, and I feel this is important, I cranked > > up the compiler settings to as high as possible. After making sure I fully > > understood all the warnings and their implications, I modified the code to > > make the compiler give no warnings. > > That's not really possible with the HiTech compilers. In the highest > setting, they give warnings about constructs that are necessary -- for > example assigning the two bytes of a 16-bit unsigned int to two separate > unsigned char. There is either something wrong with the compiler or, with your usage, because any compiler worth a penny can be used to create code that compiles without warnings and errors with the warning level set at maximum. Remember I'm not talking about code that is necessarily useful but rather a small "hello world" type program for test purposes. On actually useful code you may need to add a comment explaining why a warning is issued for a working piece of code and why you must ignore it. Now for my take on the "issue". Lint tools are an addition to the compilers error/warning system. They are meant to catch many (not all) errors that the compiler misses. There is a very large set of items Splint can check for that will not be flagged by compilers. Because 8 bit micros are unusual in the way we code them in C some of the extra checks are not going to be possible. This doesn't make it useless, it is just a little bit less useful than it is on larger micros where the C language is used more closely to the way it was designed. Commercial lint's likely do a better job of handling the quirks of C on 8 bit micros making them more useful than Splint. I've read that Gimpel software's lint is much better on embedded systems because it does allow for more error checks but using Splint is still better than using no lint at all. On 8 bit micros most programmers need to use C character variables like they are integers. On 16 bit and bigger micros, what C is designed for, using characters as integers is wasteful of the multibyte registers and architecture of the micro so, it is rarely done. So, to make Splint useful for 8 bit micros we must instruct the compiler to treat characters as integers (I use a +charint option in the project options file). By doing this we are disabling Splint's ability to see a difference between a char and an int (what we've told it to do). So with that configuration, Splint won't warn you when you assign an int to a char or, an unsigned int to an unsigned char. However, it will still warn you if you try to assign an int to an unsigned char or, an unsigned int to a char (signed vs. unsigned check). In the example you gave Splint does not issue a warning about assigning an int to a char and the compiler (I tested this with the Z8Encore compiler) also issues no error. So nothing gained and nothing lost. However if the variables are declared locally, like this: foo(void) { uint8_t n; uint16_t u; n = u; } Splint flags the error of assigning an un-initialized variable to another variable while the compiler did not. To my thinking this is very useful, sure it would be nice if Splint flagged both errors that the compiler missed but one mistake caught is much better than no mistake caught. For me the catching of = vs. ==, unused variables, assigning un-initialized variables, detecting infinite loops and, falling through switch statements (missing break;) is enough extra checking that I would still use it if those were the only mistakes it caught. Here is the part of my current projects Splint configuration file showing the checks I've had to globally disable for the Z8Encore compiler. ------------------------------------------------- # Allow character variables to be treated as numbers +charint # Allow numbers be treated as Booleans +boolint # Suppress error from main() being void in the microcontroller C -maintype # Don't report errors about "exporting" functions or variables, just # because we put them into .h files. -exportlocal ------------------------------------------------- Here's a trick to use to stop the parse errors from using non-standard constant and data types. I've used this to get code from consultants to pass lint (we don't require consultants to avoid non-standard types or use lint). This lets the code pass lint even though the CCS bit data type is used. // Bit variables for port B access #ifndef __LCLINT__ #bit bSelectSwitch = 6.4 #else #define bSelectSwitch 4 #endif This lets Splint see bSelectSwitch so that it doesn't warn of an undefined identifier while letting the compiler see the non-standard data type. In this consultants project the non-standard binary literal was also used. So I changed those lines from this: foo = 0b01011000; to this: foo = 0x58; //0b01011000 If you have further questions about Splint feel free to contact me offlist as I suspect not many others (if anyone else) on the list are interested in Splint on PIC's. Hope this helps, Paul Hutch _______________________________________________ http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist