Bug: Enum declarations inside a function may produce an lclint internal inconsistency message.
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.)
Bug: Type-checking for && and initializations break when the type is a user-defined boolean type.
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.
Bug: LCLint reports an internal bug and spurious message for some global initializations. Example:static int G = 1; int *P = &G;
Bugs: LCLint will report spurious use-before-definition errors for extern declarations within functions.
Bug: LCLint doesn't parse declarations within functions correctly. Example:void f () { enum { one, two } val; }
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); }
Bugs: LCLint may crash when checking the definition of a constant function macro.
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(); }
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]); ...
Bug: If a library type is implemented using a macro, lclint reports an internal error.
Bug: LCLint chokes on the gnu extensions __extension__ macro with bizarre syntax (even with +gnuextensions).
Bug: Message says: "Body of for statement is empy". Should be "empty".
Bug: LCLint does not handle enum definitions of the boolean type correctly (e.g.,typedef enum { false, true } bool;
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.
Bug: LCLint interprets { "hullo" } as an array who's first element is an array of chars. It should be the same as "hullo".
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