LCLint Release 2.5q

26 July 2000

Release 2.5q is a minor upgrade to the last public release, Version 2.5m.

Download

Enhancements

Boolean Checking
Fixed boolean type checking to treat user boolean types consistently. Added the -zerobool mode flag to control whether or not 0 may be treated as a boolean (the default in standard mode is to allow 0 to represent boolean FALSE, as was the old behavior).

Bug Fixes

Special Clauses at function exit
LCLint reports an internal error for violations of pre-clauses at function exits. The pre special clauses should not be checked at function exit points. (Reported by Bernd Warken).
Passing incompatible long/int pointers
If +relaxquals is set (as in standard mode), LCLint does not report an error when an int * is passed as a long int *, even though this is dangerous. (Reported by Peter van Hoof).
Mysterious Parse Errors
The parser appeared broken under certain compilers with optimizations turned on and versions of bison. This had to do with stray use of an old sgrammar.h and sgrammar_tokens.h files.
Include Files
Search path for include files in nested directories does not handle current directory correctly. (Reported by Simon Dyke)
Unnamed Array Parameters
LCLint handles int[][2] in a parameter list differently from int p[][2] (revealed through spurious incomplete type errors). (Reported by Peter van Hoof.)
Parsing malformed comments
LCLint crashes on malformed syntactic comments like /*@-PRIVATE-CALLS-@*/. (Reported by Wolfgang Stolzenburg.)
Printing long long
LCLint does not support %lld format codes in printf for long long. (Reported by Denis Baylor.)
Spurious stack-allocation errors
LCLint incorrectly assumes elements of stack-allocated arrays are stack-allocated. (Reported by Denis Baylor.)
Result Codes
LCLint does not return EXIT_FAILURE as it should when the error counts do not match. (Reported by Herbert Dietze.)
Hex Constants with UL
LCLint reports an error for hex constants ending with U and L modifiers. (Reported by David Denholm.)
Dumping special ctypes
Internal error in cttable.i when creating a library file requires a comparison between two special ctypes (e.g., "..." in function types). (Reported by Martin Smoot.)