I'm trying to come up with a scheme for linting a
large product.

The product is mostly composed of self-contained
libraries, built from source and written by
different programmers. Each library is portable to
other products, frequently updated and has its own
lint script to cope with the foibles of the
programmer involved.

We aim to lint each library on its own, but it's
been pointed out to me that we'd get greater
value-tracking coverage if we linted the entire
product source (libraries and all), instead of
doing bits piecemeal.

An example to illustrate the problem:

Library X has a function that accepts a buffer and
iterates over it. The library contains a bug that
causes the iterator to overrun the end of the
buffer. The main product source code calls into
Library X with a stack buffer and length.

When the library and product source are linted
together as source code, lint's value-tracking
will detect the overrun. When the library and
product are linted separately, the library bug
will go undetected, even with appropriate header
file annotations.

Ideally, I want to create a master lint file for
the product that references all the lint files for
each library.

Unfortunately, I cannot find a way to lint the
entire product effectively without hand-writing a
giant lint file that enables and disables error
suppression and lists every library source file --
surely not a viable option with a large and
evolving library base.

The most obvious (to me) solution -- .lob files --
does not enable inter-function value-tracking
across library boundaries.

I tried referencing the library lint scripts from
a master script, but I ran into problems where
errors, defines and includes were persisted
between each .lnt. For example, if Library J and
Library K contained a similarly named file, Lint
would complain about having seen the same file
before. -save and -restore aren't effective except
for some -e options, I gather. There were also
issues with the use of relative paths in each
library lint script vs. the master script working
directory.

So, in the experience of anyone reading this, how
does one proceed from here? Is it worth even
attempting to lint the whole product together, or
shall I just stick to linting individual
libraries, using PreFast for overall coverage?

My 5 cents worth:
Yes, it definitely pays off IMHO.
I don't know how your programmers write their 
option files, but getting a list of all source 
files is easy. Using a CMD-Shell: "DIR /s/b 
*.cpp", Unix has similar options to 'ls'.
Matching relative and absolute paths possibly is 
a matter of a simple sed/awk/... script, or use 
your favorite editor.
If the option files use '-esym(...)' instead of '-
e...' (as they should in my opinion), you may 
leave those options active globally, and simply 
merge the option files.

And if you want more option-separation between 
files, ask Gimpel support. Starting 8.00u, they 
might have new possibilities to help you there.

Anyway, the improved results are well worth the 
effort in my opinion.

Just a comparison: In a previous project I've 
tuned the Lint options for a >300 kLOC C++ source 
(from scattered to optimized) in less than two 
days. Compared to the 17 possible memory 
corruptions found (seldom executed, but definite 
errors), it has been more than worth it.

HTH,

Johan Bezem
www.bezem.de

OK, after checking with Gimpel, I can offer you a
solution to at least part of one of your problems:
> ... -save and -restore aren't
> effective except for some -e options, I gather.

Yes, you were right. However, you might try the
option '+restore_end' (Version 8.00u or later). It
is the equivalent to putting '-save' in every C
file on the first line, and a matching '-restore'
on the last line.
Beware: This is an undocumented option; it can be
changed without notice, there is no documentation,
and there is no support, all until version 9.x is
out (where it will be documented, supported, and
fixed in its form).
And now to the 'docs':
Reasoning behind this was the following: I had
some source code from a 3rd party with some sort
of waranty (guarantee? never sure which one...) on
it, 'littered' with Lint comments of the 3rd party
developers. Because of the waranty, I was not
allowed to change one iota in that source code,
not even a comment.
And, even if these comments were only found in
their C files, the options provided influenced the
processing of all subsequent C files of mine,
obscuring messages otherwise plainly visible.
Using -save/-restore in *.lnt files didn't work at
all, no matter which version of lint (design
restriction of a sort).  That's where the new
option came from, possibly useful to you too.

OTOH, if Lint is complaining about identically
named files (with different paths!) as 'seen
before', (I cannot quickly reproduce that in my
current location), I'd notify Gimpel to include
the absolute path in the comparison, at least
optionally.

Once more, globally linting your project is
definitely worth it IMHO.

HTH,

Johan Bezem
www.bezem.de

i think there is one thing that gimpel could do
for us:
if they had an option to set the current working
directory from inside a lnt file, merging of some
lnt files would be very simple

-set_cw project1
-save
...content of project1.lnt
-restore
-set_cw project2
-save
...content of project2.lnt
-restore
...

kind regards
Michael Schönherr

IMHO it is possible to write option files to be 
independent from its base directory, using 
relative paths and/or environment variables in 
the <project>.lnt files.
In my case, using a specific environment variable 
YT_PBASE for the project's base directory for 
absolute pathnames and relative paths for all 
files within the (sub-) project offers a clean 
solution to combine/recombine various modules in 
differing configurations.

The option you suggested could help a lot in 
situations where such conventions have not been 
introduced, though.

FWIW,

Johan Bezem
www.bezem.de

I can see that introducing environment variables
could simplify merging, but it would be at the
expense of either:

- Herding many variables, each representing the
root of one of 30+ libraries.
- Using a common root (e.g. %LIBROOT%) and having
to change every single -i or source path.

Faced with an uphill struggle to increase Lint use
in a lethargic population of Visual Studio
programmers, I suspect that either option could
present problems.

At the moment, they copy and paste most -d and -i
lint script settings from the VC Compiler
Configuration dialog, and run lint from the Tools
menu (roughly as described in env-vc7.lnt). This
works very well for each library project, but
obviously has its limitations in terms of setting
up an environment for lint to run inside. For me,
at least, Michael's suggested -set_cw option would
save a great deal of grief.

(Aside: It was the working directory, incidently,
that gave lint double vision. I'd attempted to use
a -i flag to effect a working dir change, meaning
that an unqualified "x.c" lnt directive in two
different scripts hit the same file twice.)

The -save and -restore options, alas, simply don't
do enough to restore the environment after the
call to a library lint script. For example, if
LibAlpha uses -dFOO, the flag will leak from
alpha.lnt to trigger a #ifdef FOO pre-processor
directive in LibBeta.

Perhaps we need a small refinement on Michael's
idea... something like this:

	-save_env
	-set_cw(Launchers\Launcher)
	launcher.lnt
	-restore_env

	-save_env
	-set_cw(Libraries\LibAlpha)
	alpha.lnt
	-restore_env

	-save_env
	-set_cw(Libraries\LibBeta)
	beta.lnt
	-restore_env

-save_env and -restore_env would work exactly the
same way as -save and -restore, but extend to all
flags (including -d and -i).

What do you think?

hello htfs,

thanks for clearing things up! Your refinement is
exactly what i had in mind. Mayby somwone from the
gimpel team can have a look at this.