We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
I believe I've got PC-Lint installed OK as per the Keil instructions, but on Linting my source it seems all the system sfr & sbits are being flagged up, eg :
"Error 40: Undeclared identifier 'ADCON'"
along with TMOD, TH0, TL0, EAL, ET0, P1, P3, P4...
These are resolved for the compiler by a
#include <reg515c.h>
Keil include file with SBIT and SFR definitions in. Lint doesn't seem to be seeing them though.
Does anyone have any pointers for me for how to fix this?
Did you feed lint your header file include paths with -i options? You have to give lint the same set of paths you give to the compiler so that it can find header files.
Yes, lint configured with paths to the projects root dir and subdir as per compiler -i options, as well as "c:\keil\c51\inc" and "c:\keil\c51\inc\infineon"
Experimenting, I copied the reg515c.h file to the project root and subdir, and added a
#include "reg515c.h"
instead of the
Lint is a lot happier with this and all the sfr and sbits in reg515c.h are now not thrown up as undeclared identifiers. I thought the <> on the include told the compiler to search the system include paths verses "" telling it to search the -i passed include paths. Lint would be seemingly missing the <> included headers?
'Course, now I'm getting lots of "Info 714: Symbol 'xxx' not referenced" and "Warning 552: Symbol 'xxx' not accessed" so I need to turn them off...
I'd have to crack the spec to be sure what standard behavior really is -- if it's not just "implementation defined".
But in my mind, #include "" means search the directory containing the including file, then the 'path', while #include <> means search the 'path'. The 'path' is defined by tool-specific means: -i for PC-Lint (and for most compiler command lines).
So it would seem that there's something wrong with the definition of the path. Changing to "" and moving the file to the project root works because of that first step in "" processing. But lint should be able to find the file in the installation directory.
See Section 6.1 of the PC-Lint manual for a discussion of "library" headers. #include<> is one of the ways lint assumes that a .h file is a "library" header, and thus knows not to complain about unused items in the header. #include"" is not automatically a library header. So, if you want to keep using #include "" for the register.h, then you might want to use +libdir or +libh to mark that directory/file as a library header.
(One of the nice things about PC-Lint is that it's very configurable. One of the bad things about PC-Lint is that it's very configurable...)
Thanks for the info re <> being "library" headers, now I know what to call them to differentiate them from "" (non-library?) headers. Off to read the manual next!