Deutsch
English
NederlandsJohan Bezem ist Mitglied bei
Gimpel announces a new version of PC Lint: 9.0!
I guess the word is out:The press release is online.
I’ve had the pleasure of being a beta-tester for this version, and even though I’m an experienced user of version 8.0, I must admit that I’m impressed: I would never have believed that such a functionality increase would have been possible. Lint 8.0 already is really good, it’s amazing that Lint 9.0 can offer so much more.
Recommended!
Happy linting!
GNU make meets Visual Studio (automagical make part 5)
Another automagical step!
I’ve split up the one makefile into more manageable pieces, organized for easier reference and better topical coherence. I’ve reinstated the support also for CMD.EXE (in addition to Cygwin/bash and Linux), and introduced the Visual Studio C/C++ compiler in parallel to GCC.
All with updated documentation as usual in a neat package. It’s not ready yet, but we’re getting there.
Take a look at http://www.bezem.de/i_make.html.
Happy making!
Johan
GNU make learns how to compile (automagical make part 4)
I’ve created the next instalment of my makefile template, available at http://www.bezem.de/i_make.html. In this instalment, I show how to call the compiler (for now, only GCC using cygwin), how the ‘vpath’ is working, provide a simple ‘clean’ target, and show a few tricks.
Happy making!
Johan
Automagical make: 3rd instalment
After providing some (empty) source files in the directory tree, I taught the template to create object files, albeit still using ‘touch’ instead of a real compiler. That will have to wait for one of the coming instalments. Look at http://www.bezem.de/i_make.html
Happy making!
Johan
Heads-up: Gimpel released patch version 8.00x
If you’re not a regular reader of the Gimpel forum on PC Lint, please be aware that Gimpel released the next patch version of PC Lint, 8.00x. Several smaller errors are fixed, some support files have been updated (don’t forget the read80.txt and the bugfix80.txt).
And finally, support for Visual Studio 2008 is added.
If you’re a user, have a look at the patches page.
Happy Linting!
Johan
If you’re serious about GNU make, you have to read this
For easy reference, I’ve composed some links to websites you need to know about if you do more than just tweak some GNU makefiles.
First, there’s the source of all:The project’s pages on Savannah as maintained by Paul D. Smith, and the manual in PDF as published by the FSF.
The next resource is the website of Paul D. Smith himself, with some links, but especially the white papers are gold.
And the I’ve recently (re-)discovered Mr. Make, John Graham-Cumming: A column at CM Crossroads especially on GNU Make and its surroundings. I need not always share his opinion to value his tips and tricks.
Brad Appleton in his blog collected several links on the (dis-)advantages of recursive make, it’s good to know the reasoning behind the topics, as well as the proposed solutions.
And, of course, even though it has been linked many times already, the paper that gave birth to my project (but to prove it wrong!), “Recursive Make Considered Harmful”, 1997 by Peter Miller.
Start with GNU make and its manual, take Paul’s white papers to get it right, take John’s tips to make it better and more efficient, and see for yourself what can be done using my concept ;-)
Happy Making!
Johan
Automagical make: 2nd instalment
Magic make learns to crawl. It still doesn’t do much, but it now switches over from the source tree to the objects’ tree to traverse the source tree from a created parallel ‘universe’ where the intermediate files shall reside. Again, a PDF grown to 10 pages, as well as the latest directory-copy for you to follow along, available at http://www.bezem.de/i_make.html.
Happy Making!
Johan
Gone is the build-system-maintenance-nightmare
OK, to be honest: It isn’t quite gone. But it’s become very small, and no longer a nightmare.
You ask why? Because it now operates automagically.
You ask how? By deducing what directories contain relevant sources, by finding out where the include directives are located, by compiling all sources it can (or is allowed to) find, and create an executable for that. Or more than one. Or a library.
You ask where? Well, here: http://www.bezem.de/i_make.html
I’ve started documenting a make structure based on GNU make, with little else in form of utilities (one of my own will be presented with full source code), automating most of the build process itself.
- platform-independent using GNU make
- no more makefile-maintenance to add files or directories
- multiple versions in one project tree, keeping the sources together while separating the intermediate files as well as the results
- full dependency checking included, automatically
- dependencies between directories can be indicated and will be observed
- hardly slower than running a flat makefile, just as fast as a normal recursive make
OK, where’s the catch, you ask? No catch. This system has been up and running in at least three development locations, on Solaris, HP-UX, AIX, Windows 2000, Windows XP, with and without Cygwin, using a variety of compilers (including GCC and Microsoft VC++), with implementations for various assembler languages, C, C++, lex/yacc and IDL.
If there is a catch it is this: I’ve now started documenting the system and the concepts in a way for developers to understand the reasoning (I have documentation on the innards as well as for the user, but too specific for publication), and for others to tailor the ideas to their environments, if necessary. And, sadly, that work has just started.
The first installment is online, illustrating how GNU make can find the directories intended to be included in the build by looking (recursively, with arbitrary depth) for directories containing a file called ‘Makefile’, and illustrating how to represent dependencies between sibling-directories that even will be honored by parallel-make.
Maybe not much, but then, more is to come, so register here, or watch the RSS!
Happy Making!
Johan
Updated version of “How to wield PC Lint”
With some more experience from some different environments, I have felt the need to update my document on “How to wield PC Lint”. The main changes I made to the document:
- the Gimpel-provided compiler support files ‘co-*.lnt’ may be a fair starting point, but certainly not the final word;
- I changed the name for my output file to ‘lintout.out’, for one project the names ‘error’ and ‘errors’ were already in use, and using the extension ‘lnt’ doesn’t seem a good idea anymore;
- I now use quotes around the filename for Lint’s output messages, to accommodate environments using spaces in path names;
- I added a warning about suppressing errors numbered less than 400;
in addition to some small corrections.
Have fun!
Johan
PolySpace – pros and cons
I have some experience with a static (or quasi-dynamic) code-checker named PolySpace.
And since several requests have reached me to comment on the usefulness of PolySpace, sometimes in comparison with PC Lint, I decided to share some of my experiences with my (hopefully large) audience.
I used version 2.6 IIRC more than two years ago. However, the observations noted here were written down less than a year after that, and backed-up with a complete experience report written in parallel to my activities as a sort of diary. Memory lapses therefore unlikely.
I have made following observations on the deployment and use of PolySpace for embedded systems:
- PolySpace starts its operation with a GNU-compiler run locally on the users machine, and being far more picky than most compilers:
- Macro redefines (without#undef) are not allowed
- An unused macro parameter is not allowed
- Function call without parentheses is not allowed (this is a real error, resulting in a function pointer; however, some compilers just warn, and “do the right thing”, like the GreenHills compiler)
- a macroassertis not allowed, since this would redefine an ANSI macro/function
- Too many braces in struct-initializers are not allowed, i.e.int myArr[2] = { { 5, 1 } };
- Bit fieldunsigned long bf:32is not allowed; justunsigned int bf:32; for widths less than 32 (long size?), no such limitation seems present
- Include filenames with a trailing space are not allowed, i.e.#include "abc.h "
- All prototypes must be available, correct and visible on use
- Inlining can be tedious, especially wheninlineis implicitly taken to meanstaticas with some compilers possible. Be aware: PolySpace warnings/errors in these cases are in no way always to the point and useful. In several cases it has proven necessary to dig quite deep into PolySpace innards and/or to refer to PolySpace support in order to understand why processing wasn’t successful. - Several concepts are tedious to accommodate with PolySpace, and may lead to red errors (errors stopping the processing at that point)
- All variables must be initialized in a way recognizable for the GNU compiler
- Backwardgoto‘s must be instrumented with special PolySpace macros (changes in source code unavoidable!)
- Some forms of assembler need to be stubbed, since just disabling the assembly code may lead to a missing or empty function
-assert(false)orassert(0)is not allowed, not even in conditional code, and leads to red errors, stopping the processing of the rest of the function
- Functions known not to terminate must be conscientiously indicated
- All task entry points (in addition tomain) must be indicated, as well as the ISR entry points
- Only functions with the prototypevoid <function>(void)are allowed as entry points for PolySpace
- Assignment of enum values to bit fields (even if the value range basically fits) can only be performed masked to the width of the bit field, even if the bit field has been declared with the enum-type as base
- If specific input conditions are implicitly assumed, and violation of those could/would lead to red/abort errors in PolySpace, these conditions must be made explicit by using asserts - Aside from the long running times required (more than four days on ‘Software Safety Analysis level 2′ with ‘-O2′), the welcomed option “continue-with-red-errors”, which enables one to find multiple aborting errors in one PolySpace run, may cause spurious red errors also, and makes it tedious to find the source of a series of red errors
- Deployment: If the client version and the server version differ even in minor parts of the version number, finding the cause of inevitable failures is very difficult, since the only clear-text error message is deposited in a cryptic log file normally ignored as part of the PolySpace noise
- Deployment: PolySpace on Windows needs its own version of the Cygwin environment; one cannot install PolySpace without also installing Cygwin. Since it is problematic to have more than one Cygwin installation on one machine, other tools and environments cannot be used on the same machine. To my experience this includes the Standard Core development environment from BMW/3SOFT as well as the testing tool Tessy, among others. And since PolySpace will not run with a different version of Cygwin, this might limit its deployment options. Full runs on a (Linux?) server are possible only if and when the server has access to the original sources, through Samba, FTP, NFS, or whatever. Depending on the regular development environment, this may be tedious but possible.
- Most important in my opinion: Mutual exclusion primitives must always appear in pairs within the same scope, like e.g. DI/EI. However, with an operating system like OSEK or VxWorks (or similar), sometimes constructs exist that do not appear in pairs (like ‘osSaveDisableGlobal’ only uses ‘DI’, whereas ‘osRestoreEnableGlobal’ only uses ‘EI’), or one has three primitives, two for setting and one for clearing (like ‘setLocal’ and ‘setGlobal’ vs. ‘clearAll’). Such combinations cannot be accommodated in
PolySpace. The idea was to add extra (empty) macros for use as PolySpace guards. However, only code reviews could ascertain that such guards had only be placed at the appropriate code lines, and nowhere else. Recommendation even from PolySpace support (!!) was to concentrate on the code reviews, and refrain from implementing such primitives in the code to have PolySpace check the multitasking accesses. Thus, I have no experience with the problematic cases PolySpace would be able to find.
I have worked with PolySpace for some three months on a project with roughly estimated 50 kLOC C code (Counted semicolons outside of comments/strings, but fair enough). I cannot assume to have seen all potential road blocks using PolySpace, as I cannot assume that all described road blocks will prove relevant for your C code. Using PolySpace for C++ was outside my scope. Therefore, these observations are just that: observations.
And please be aware: This was version 2.6, PolySpace has not halted development, and it might very well be that some of the issues mentioned here have been resolved
already.
And on the other hand, the things that PolySpace finds can be amazing: If a function creates a divide-by-zero runtime error when called with a parameter value of, say, 32,
PolySpace will find that. It will find effectively unused code, even if the conditions are far from trivial, and many other things.
OK, Lint will find much for you. If your code is Lint-clean, and both PolySpace and Lint have been properly configured, PolySpace will find few (but probably serious) errors,
if any. So, if you have the money, resources and time to use PolySpace, use both: Lint on a daily basis, available to all developers, with a clear message that code shall be clean before being checked-in. And well in advance of the next release, do a full PolySpace check, and take the warnings seriously.
Happy debugging!