Bugs Fixed

This page documents reported bugs in LCLint 2.1b that are (believed to be) fixed in LCLint 2.2.

inner enum declarations

Bug: Enum declarations inside a function may produce an lclint internal inconsistency message.

scanf arguments

Bug: The expected types of %f and %lf are wrong. LCLint expects double and long double, but they should be float and double. (Note this is different from printf.)

Boolean operators

Bug: Type-checking for && and initializations break when the type is a user-defined boolean type.

Casting structures

Bug: If a structure is cast to another structure, and then a field (that is not part of the original structure type) is selected, lclint will report an internal error.

Initialization

Bug: LCLint reports an internal bug and spurious message for some global initializations. Example:
static int G = 1;
int *P = &G;

nested extern declarations

Bugs: LCLint will report spurious use-before-definition errors for extern declarations within functions.

inner enum declarations

Bug: LCLint doesn't parse declarations within functions correctly. Example:
void f ()
{
   enum { one, two } val;
}

offsetof...typename

Bug: (cause not completely confirmed, believed to involve type name being processed as undefined identifier after offsetof)
Example:
void f1 (int n_bytes)
{
    f2 ((int) offsetof (some_struct, sf3));
    f3 (0, 0, (U_type *)&x, 0);
}

parsing function macros

Bugs: LCLint may crash when checking the definition of a constant function macro.

index modifications

Bug: LCLint does not recognize a modification of *x as changing the value of x[0]. This means incorrect infinite loop messages may be reported, and certain other errors may be missed.
Example:
int main(void) {
    char buffer[6];
    ...
    while (buffer[0] != 'x') {
	if (fgets(buffer, (int)sizeof buffer, stdin) != buffer) abort();
    }

array/function

Bug: LCLint assertion fails when a variable declared as a function is used to index an array:
char *text(int i);

...
printf("%s",text[1]);
...

#define type

Bug: If a library type is implemented using a macro, lclint reports an internal error.

gnu extension __extension__

Bug: LCLint chokes on the gnu extensions __extension__ macro with bizarre syntax (even with +gnuextensions).

mispellings in error messages

Bug: Message says: "Body of for statement is empy". Should be "empty".

enumerated boolean types

Bug: LCLint does not handle enum definitions of the boolean type correctly (e.g.,
   typedef enum { false, true } bool;

break/continue semantics

Bug: LCLint does not interpret break and continue statements in control flow analysis. This means code like,
	if (x != NULL) break;
	*x = 3;
will produce spurious messages.
Workaround: If else is used for the other branch, checking works correctly.

braketed string literals

Bug: LCLint interprets { "hullo" } as an array who's first element is an array of chars. It should be the same as "hullo".

standard library tags take precedence

Bug: If a structure tag is declared in a system header file and a user file, the system header version takes precedence, and no error is reported. An error should be reported, and (perhaps) the new declaration should be used.

Bugs in Version 2.1a that are fixed in Version 2.1b


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