Introduction
LintProject is a command line tool intended to make the process of using the PC-Lint code analysis tool (produced by Gimpel software) with Visual C++ projects a little easier and more productive.
PC-Lint analyses C++ code to identify potential problems. By comparison with a C++ compiler such as that provided with Visual C++, it is highly customizable and very thorough, but (understandably) significantly slower. The output it produces is file based, and directed to the console by default, for example:
--- Module: CJFlatHeaderCtrl.cpp
} CJFlatHeaderCtrl.cpp(160): error 1401:
(Warning -- member 'CCJFlatHeaderCtrl::m_bSortAsc'
(line 146, file ..\Include\CJFlatHeaderCtrl.h) not initialized by constructor)
}
CJFlatHeaderCtrl.cpp(166): error 1740:
(Info -- pointer member'CCJFlatHeaderCtrl::m_pParentWnd'
(line 150, file ..\Include\CJFlatHeaderCtrl.h)
not directly freed or zeroed by destructor -- Effective C++ #6) ---
Global Wrap-up error 900: (Note -- Successful completion, 2 messages produced)
Although PC-Lint does a great job of analysing C++ source and header files for potential problems, it is a generic cross-platform tool, and as such, its integration with development environments is limited. For example, when used with Visual C++, PC-Lint can be used to scan the current file for warnings and to direct the results to the Output window, or to scan a list of files defined in a text file.
While this level of integration is just about adequate under some scenarios (for example, when developing new code), it is less than ideal if you want to perform a complete analysis of an entire project or solution. Furthermore, since PC-Lint does not provide any means of generating useful reports on the results, it can be difficult to spot potential problems amongst the mass of results.
If you are working with a large project, these limitations can make using PC-Lint to analyse your code time consuming and difficult, which can potentially be a real disincentive to using this very useful tool on a regular basis. As a result, the quality of your code could well suffer.
LintProject was written to address two of these issues. Unlike PC-Lint, LintProject can read both Visual C++ project and solution files. It can be run against either a complete solution or an individual project:
- When run against a project, it reads the Visual C++ project file (*.dsp, *.vcp, or *.vcproj) and instructs PC-Lint which files to analyse. For each file analysed, the PC-Lint output is captured and recorded in a text file for later analysis.
- When run against a complete solution, LintProject reads the Visual C++ solution file (*.sln, *.vcw, or *.dsw) and recursively analyses the projects it contains.
XML and HTML Reports
Whilst the availability of text files containing the results of the analysis is an essential result of the process, without a means of summarizing their contents and indexing them, the process of interpreting the results is likely to be slow and laborious.
LintProject provides a convenient solution to this problem by writing XML and HTML reports which link to the results files, and indicate how many warnings were found within each implementation file, project, and solution:
Example HTML output
A key design aim of LintProject was to be capable of indicating its process whilst it runs. This is especially important when you consider that a PC-Lint analysis of a large project can take considerable time on some systems. To achieve this aim, the output reports produced by LintProject are automatically regenerated as the analysis progresses. Even better, any supported browser windows* displaying the corresponding results files will automatically refresh as each file is analyzed. This gives immediate feedback on the progress of the analysis, and is proving to be a very useful feature.
* At present, this feature only supports Internet Explorer and derived browsers such as Crazy Browser, Avant browser, etc.
Installation
Installation of LintProject is straightforward. The simplest method is simply to place the executable (LintProject.exe) into the same folder as the PC-Lint executable (lint-nt.exe). If you prefer to locate LintProject.exe elsewhere, the /f switch can be used to tell it where to find the PC-Lint executable.
Using LintProject
LintProject is invoked by a simple command line, for example:
There are several options:
-
/f<FolderName>
Specifies the location of the LintProject executable. This is only required if LintProject is installed in a different folder from the PC-Lint executable.
-
/configfile"<filename>"
Specifies the filename of the Lint indirect file to use. If omitted, std.lnt is assumed.
-
/cfg"<configname>"
Specifies the solution configuration to be analysed.
-
/exclude"<projectname1>,<projectname2>,..."
Specifies the names of projects to exclude from the analysis.
-
/l"<parameters>"
Passes the following parameters to the PC-Lint executable (lint-nt.exe). For example, /l" -background" will instruct PC-Lint to perform analysis at a low priority.
-
/s
Specifies that the HTML output should be automatically opened in a browser window when analysis starts.
-
/?
Display help information.
LintProject runs the PC-Lint executable (lint-nt.exe) on each source file individually, instructing it to redirect its output to a text file which is linked to from the corresponding HTML report. For each file, a command line such as the following is used:
<lint-folder>\lint-nt.exe -i"<lint-folder>" -b -u std.lnt
env-vc6.lnt -i"Debug" <source file> >Lint\<source file>.txt
std.lnt and env-vc6.lnt are standard options files produced by the PC-Lint installation - the latter being specific to Visual C++ 6.0 projects. Although the PC-Lint installation will install only one such file into the PC-Lint installation folder by default, copies of the others are available in the lnt subfolder.
LintProject will use env-vc6.lnt for Visual C++ 5.0 and 6.0 projects (<projectname>.dsp), and env-vc7.lnt for Visual C++ .NET projects (<projectname>.vcproj), so it is a good idea to place the options files you expect to use in the PC-Lint installation folder itself.
Source Code
LintProject is a fairly straightforward command line application built using ATL7. Originally, MFC was used (more for convenience at the time than anything else - the classes used to parse Visual C++ solution and project files were originally taken directly from ResOrg, and originally written under MFC). The dependency on MFC has since been removed.
Parser and utility classes aside, LintProject essentially consists of three classes - CFileLintAnalyser, CProjectLintAnalyser, and CSolutionLintAnalyser - which together control the entire process of analysing the specified project or solution. These classes invoke PC-Lint, index its output, and generate output reports in both XML and HTML formats (the latter by transforming the XML using XSLT stylesheets).
One issue which became apparent early on was that the time taken to analyze a complete project using PC-Lint can be very significant as a consequence of its depth of coverage. To allow the user to see the progress of the analysis, LintProject regenerates its output reports as the analysis progresses. An added dimension is its ability to refresh any browser window on the host PC displaying its reports as the analysis progresses (it's actually quite mesmerizing watching the warning count steadily climb...)
Implementing the browser refresh is one of those techniques which falls into the category of "easy once you know how". It is achieved by enumerating all of the WebBrowser controls open on the local machine using the SHDocVw::IShellWindows interface (see MSDN KB article 176792 - "How To Connect to a Running Instance of Internet Explorer").
For each control retrieved, the URL it is displaying is compared with the canonicalised pathname of the report which has just been updated. If they match, the control is refreshed, causing the updated version of the report to be displayed:
bool RefreshAllOpenBrowserWindows(const CString& sFullPathName)
{
if (sFullPathName.IsEmpty() )
{
return false;
}
DWORD dwLen = _MAX_PATH;
CString sCompareURL;
if (!::InternetCanonicalizeUrl(sFullPathName,
sCompareURL.GetBufferSetLength(_MAX_PATH),
&dwLen,
ICU_BROWSER_MODE) )
{
return false;
}
sCompareURL.Replace( _T("//"), _T("///") );
sCompareURL.Replace( _T('\\'), _T('/') );
sCompareURL.MakeLower();
SHDocVw::IShellWindowsPtr shellws = NULL;
bool bSuccess = true;
try
{
HRESULT hr = shellws.CreateInstance(__uuidof(SHDocVw::ShellWindows));
if (FAILED(hr) )
{
throw hr;
}
long lCount = shellws->GetCount();
for (int i = 0; i < (int)lCount; i++)
{
_variant_t vtIndex( (long)i);
IDispatchPtr idisp = shellws->Item(vtIndex);
if (idisp == NULL)
{
continue;
}
SHDocVw::IWebBrowser2Ptr pWebBrowser = NULL;
hr = idisp->QueryInterface(IID_IWebBrowser2, (LPVOID *)&pWebBrowser);
if (pWebBrowser != NULL)
{
_bstr_t bsURL = pWebBrowser->GetLocationURL();
CString sURL((LPCTSTR)bsURL);
sURL.MakeLower();
if (sURL == sCompareURL)
{
hr = pWebBrowser->Refresh();
if (SUCCEEDED(hr))
{
TRACE("browser refreshed correctly\n");
}
}
}
}
}
catch(...)
{
bSuccess = false;
}
shellws.Release();
return bSuccess;
}
Unfortunately, this technique works only for Internet Explorer and derived browsers. Similar techniques could, of course, be used with any other browser which offers a COM interface and a method of enumerating open windows at a system level. If anyone knows of comparable interfaces which will work for Mozilla, Firefox, and Opera, we would be very interested to hear about them.
Finally, despite appearances to the contrary, LintProject is single threaded. Whilst it could have been written to spawn multiple analysis threads (as Visual Lint does), the extra complexity this would cause just did not seem worthwhile, given its original target use of running with an overnight build.
FAQ
Can I Use LintProject on its Own?
No. To use LintProject, you must have a licensed copy of PC-Lint. Please contact Gimpel Software for ordering information for PC-Lint.
Which Platforms does LintProject Support?
LintProject should run on any system supporting Windows 2000 or later. This restriction is solely the result of the use of the Win32 function SHCreateDirectoryEx(); if you need a version of LintProject which runs on Windows 9x, please contact us and we will be happy to prepare a version without this restriction.
Which Versions of Visual C++ is LintProject Compatible With?
LintProject is compatible with projects and solutions for Visual C++ 5.0, 6.0, Visual Studio .NET 2002, 2003, 2005, and 2008, as well as eMbedded Visual C++ 4.0.
Compilation of the LintProject source requires Visual C++ .NET 2003 or later.
What Configuration does LintProject Require?
None. Simply place the executable into the same folder as the PC-Lint executable (lint-nt.exe), and it should work quite happily.
If you prefer to locate LintProject.exe elsewhere, the /f switch can be used to tell it where to find the PC-Lint executable.
Can I Pass my Own Parameters to the PC-Lint Executable?
Yes. You can use the /l switch to pass parameters directly to lint-nt.exe.
I have Windows XP Service Pack 2 Installed, and Some of the Links in the Reports Don't Work
This is a direct result of the "Local Machine Zone Lockdown" policy introduced in Windows XP SP2, which prevents active content (including JavaScript code, which is included in the HTML reports to provide table sorting facilities) from running when HTML pages are accessed locally.
The following articles discuss the lockdown and its implications:
According to the articles we've read on this, it should be possible to circumvent this by adding "The mark of the Web" (in Microsoft terminology) to the generated HTML. Unfortunately, so far, this has proved unreliable or has had unwanted side effects. We will continue to look for a way to circumvent this restriction, but for now, it can be worked around quite simply by either clicking on the Information Bar when the warning appears and selecting the "Allow Blocked Content" option, or checking the "Allow active content to run in files on My Computer" option in the "Advanced" page of Internet Options:
Note that this issue only affects Internet Explorer. Other browsers should be unaffected.
Which Additional System DLLs does LintProject Require, and What Versions?
LintProject requires MSXML2 or later to generate HTML reports. Although it should be installed by default on Windows XP systems, it can be manually installed, if necessary, by installing the XML SDK (supplied with the Platform SDK).
Aside from MSXML, LintProject should not require any additional system DLLs to be installed. Please let us know if you have difficulties using it on your system.
Finally...
The original version of LintProject was written by Anna during her employment at Sonardyne International Limited. We would like to express our gratitude to them (and in particular, Bruce Baker and Richard Baldock) for agreeing to release ownership of the source to us so that we could maintain and further develop it.
LintProject is freeware. You may use it without restriction, provided all copyright notices in the code and stylesheets remain intact. We hope it proves to be as useful to you as it has to us, and we welcome your suggestions for future enhancements and improvements.
For the latest information on LintProject, please visit the Riverblade website.
Version History
Version 1.4.1.13 (January, 2009)
- Modifications to support $(PlatformName) with VS2002 onwards. Our thanks to Alex McCarthy for contributing these changes.
- LintProject now returns an error code of 1 in the event of an error in the command line. Our thanks to Brett Rowbotham for contributing this change.
- The elapsed time value in project reports now shows hours as well as minutes and seconds (preventing an incorrect elapsed time from being reported for projects which take over an hour to analyse). Our thanks to Brett Rowbotham for contributing this change.
- Removed the unused LintProject.h.
- Updated the MSXML import in stdafx.h from msxml2.dll to msxml4.dll and added the
named_guids qualifier.
- Modifications to support $(SolutionDir) and $(ProjectName). Our thanks to Alex McCarthy for contributing these changes.
- Removed a redundant declaration in CFileLintAnalyser.
- Changed LintProject.zip to LintProject_1.4.zip in MakeZip.bat.
Version 1.4.0.10 (July, 2008)
- Removed all MFC dependencies. LintProject now uses ATL 7 directly, and in consequence, the source now requires Visual Studio .NET 2003 or later to compile (project files are supplied for Visual Studio .NET 2003 and Visual Studio 2008, but porting to other versions should be straightforward).
- Converted the build to Unicode.
- Added support for eMbedded Visual C++ 4.0 workspaces and projects.
- Solution and project specific environment variables $(SolutionDir), $(ProjectDir), $(InputDir), and $(ConfigurationName) are now set during analysis. Our thanks to Andrej Pohlmann for contributing the code to implement this feature.
- If a file of the form .options.lnt is found in the project folder, it will now be used in the analysis command line. Our thanks to Andrej Pohlmann for contributing the code to implement this feature.
- Added error checking for solution/project configurations (attempting to analyse an invalid configuration will now cause an error to be generated).
- Visual C++ 6.0 project (*.dsp) files containing only one project configuration are now parsed correctly.
- Added a /exclude parameter to allow specified projects to be excluded from analysis (our thanks to Andrej Pohlmann for contributing the code to implement this).
- Integrated the solution and project file parsers from Visual Lint, along with various utility functions.
- Corrected a potential buffer overflow in the loading of XSL stylesheets (thanks to Mark Ridgwell for identifying this).
- Corrected a bug in the parsing of intermediate file folders within Visual C++ projects.
- Reinstated a missing -u option in the analysis command line.
- Added the application version to generated reports.
- Fixed a potential COM exception in
Utils::RefreshAllOpenBrowserWindows().
- Fixed minor Lint issues.
- The code is now released under the Code Project Open Licence (CPOL) v1.0; file banners have been updated accordingly.
Version 1.3.1.7 (June, 2007)
- Added the /configfile switch to allow the name of the std.lnt file to be specified.
- Incorporated customer requested fixes and corrections.
- Started removing MFC specific code.
- Fixed most outstanding Lint issues.
Version 1.3.0.6 (March, 2006)
- Added support for Visual Studio .NET solution configurations. The solution configuration can now be specified directly, with the corresponding configuration for each project being selected automatically.
- Added the /cfg? parameter to allow the available configurations to be queried at either solution or project level.
CSolutionLintAnalyser and CProjectLintAnalyser now only attempt to refresh browser windows if the /s parameter is specified. This prevents problems when the utility is run as a service.
Version 1.2.4 (March 2005)
CSolutionLintAnalyser::Analyse() and CProjectLintAnalyser::Analyse() now use SHCreateDirectoryEx() instead of mkdir() to create folders for analysis results so that recursive folders are automatically created. Note: this function requires Windows 2000 or later.- Fix to UNC path checking suggested on the LintProject CodeProject forum.
- Improved handling of relative pathnames. Analysis and source files no longer need to reside on the same logical drive.
- Added support for passing parameters directly to lint-nt.exe via a new command line option (/l"<params>").
- If a warning count of 255 is returned from lint-nt.exe,
CFileLintAnalyser::Analyse() will now parse the results file to try to retrieve the true warning count.
- Re-implemented the
FileExists() helper function.
- Added solution to source code control.
- Modifications to allow operation on systems where PC-Lint is installed in a pathname containing spaces (e.g., C:\Program Files\Lint).
Version 1.2.2 (October, 2004)
LintProject version 1.2.2 released to CodeProject.
