Bugs Fixed

This page documents reported bugs in LCLint 2.2a that are (believed to be) fixed in LCLint 2.3f.

bug in list_grow functions

A bug in the list_grow function may lead to the incorrect amount of space being allocated (reported and fixed by Florian Weimer).

# define inside struct declaration

Pre-processor command inside struct declarations confuse the parser.

nested sizeof

modifies clause for old-style function produces internal error

annotations on gmtime and localtime

The return values were annotated with only, should be observer.

bool declarations

-booltype does not work correctly.

library state information

Library files may lose null state information for some constants.

hex constants

LCLint incorrectly assigns value to hexidecimal constants (0x42).

implicit types

LCLint reports erroneous errors for initializations like,
	static const dummy[] = { 0x0 }
because of the unknown (implicitly int) type. The imptype flag was added to control reporting of declarations with implicit types.

local static declarations

LCLint view local static declarations as global (for namespace checking).

Duff's Device

LCLint fails with internal error on Duff's Device. (Some may claim this as a feature, but it is fixed regardless!)

+= operators lose modification information and are not fully typechecked

Modification information in the right operand of a += is not propagated correctly. This may lead to spurious infinite loop messages:
        while (*name != '\0') h += *name++;

notreached doesn't prevent path with no return messages

The /*@[email protected]*/ comment does not prevent path with no return messages from being issued.

obvious infinite loop constructs

LCLint doesn't interpret for (;;) or while (TRUE) as obvious infinite loops, and may generate spurious function-without-return and related errors.

declaration parameter names in pre-ANSI declarations

"Declaration parameter has name" errors are produced for old-style declarations under certain conditions.

floating point comparisons

LCLint produces an unclear message when floats are compared to FLT_EPSILON using > or < (instead of >= and <=).

bsearch declaration

The declaration of bsearch in the standard library, ansi.h is missing a /*@[email protected]*/ annotation. It should be:
extern /*@[email protected]*/ /*@[email protected]*/ void *
  bsearch (void *key, void *base, 
	   size_t n, size_t size, 
	   int (*compar)(void *, void *)) /*@*/ ;

initializations

Some initializations lead to an internal error.
static char x[20];
char **p = &x;

bit ops

LCLint does not report errors when bitwise operations are used on signed integral types. (The +bitwiseops flag was added to control this checking.)

scanf arguments

LCLint misinterprets modifiers in scanf arguments (e.g., %lf).

manifest arrays

LCLint reports an incorrect manifest array error for declarations like int x[][10].

array/pointer branches

LCLint may report an internal error (and crash) if the same storage is used as both an array and pointer in different branches of one conditional, followed by another branching construct.

These bugs were present in the original 2.2 release, but were believed to be fixed in the current 2.2a release:

structure fields

LCLint may incorrectly match untagged structure fields (e.g., typedef struct { float a; } s1; typedef struct { double a; } s2;), leading to the a field of s2 incorrectly having type float.

compdestroy recursion

LCLint processes a too-deep alias nest when checking undefined regex_t structures in rx.h.

internal bug buildNCField --- no field ...:

When structures are cast to different types, and then a deep structure field is accessed, LCLint may produce an internal bug report.

Bugs in Version 2.1b that are fixed in Version 2.2


LCLint Home Page David Evans
University of Virginia, Computer Science
[email protected]