PC-Lint, uV3, infineon C515C

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

#include <reg515c.h>

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

Greg;
I agree with Drew's statement but I suggest that you
use the 'SetUp' dialog under the Tools menu. I believe your post implies that you did just that. Did you select the correct lint Configuration File in Keil/C51/Bin? Something like CO-KC51.LNT.
This is a text file that you can open and modify per
PC-Lint specs. In the file, you should see the SFR entries that have been defined as 'Ignore' For example
-esym(14,ADCON...) which I see in the file.
But your symptom, as Drew points out, is a missing include file or an incorrect include file that does not define ADCON.
Also, remember the order of the include files entered
in the PC-Lint Include Folders dialog. PC-Lint scans
from the first Include File entry to the last. So always place your project header path as the first entry and then add second and third entries for the Keil paths to their include folders.
Bradford

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!

Indeed, configuring PC-Lint through the uV3->tools->setup PClint dialogue box.
I had got the following in there :

.\ 
.\common\ 
C:\Keil\C51\INC\ 
C:\Keil\C51\INC\Infineon\ 

More experimenting; removing my project local copy of the reg515c.h library header, reverting the C source to #include it as <>, and changing the first two project include paths to be the full directory names pathed from C:\ down, rather then the relative ones, and Lint is now parsing all the include files correctly.
When I've finished the static code analysis summation that was required, I'll try to find the time to try to explain why it now works ;)

PS: ADCON was a red herring in that it is used in an #ifdef...#else...#endif section for a build for a different 8051 variant of the common code (the C515C doesn't have an ADCON SFR). Short of putting the project options C51 tab define (cmd line -d) of "C515" into the C source, how does Lint know what external defines have been defined?
I know, I'll go read the manual like I said I was going to do!

Much as with include paths, you need to define preprocessor symbols for lint as you do for your compiler.

Usually, I take care of this chore in the build tool (jam, make, whatever you like). Ideally your project build system lets you list the symbols and can wrap them in appropriate syntax for various tools like the compiler and lint.

Another strategy is to create an "project.h" which includes all the #defines that select options for the project, and have all header files include that first, so that the options can affect those headers. Then there's one common place to adjust the options that's not the command line of the various tools.

In general, I prefer to avoid conditional compilation in the first place; This is one of the reasons why.