at the lexical analysis stage not at the syntax parsing stage. The upshot
is that:
if (expr) {
stmt1;
}
/* LINTED */
stmt2;
stmt2 is the look-ahead token for the parser to choose between and if-then-else
statement as opposed to an if-then statement. Unfortunately the side effect
is that the LINTED directive gets reset before stmt2 gets parsed. We fix this,
by remembering the the linted directive during the if statement parsing and
restoring it at the appropriate time.
place" (e.g., when DESTDIR is set). This causes the lint driver to
pass -nostdinc -idirafter <dir> to cpp, causing it to ignore
/usr/include and look somewhere else instead..
used as lint1 input. That involves having lint pass the '-' through
to the cpp which preprocesses the lint1 input, and having lint1's
scanner recognize a cpp filename "" as "{standard input}".
convert them to pointers. If they're zero, they're converted (to
NULL pointers) regardless of size. If they're non-zero, they can't
be converted (without a cast). This matches the behavior of other
version of lint, e.g. the lints on Digital UNIX and HP-UX.
* recognize that pointers to identical unnamed and untyped structs,
unions, and enums are, in fact, identical. This is done by tagging
each of unnamed and untyped structure, union and enum with a unique
position of creation, which is used as a unique identifier that
when determine whether or not a pair of structures, unions, or enums
are identical.
unions, and enums are, in fact, identical. This is done by tagging
each of unnamed and untyped structure, union and enum with a unique
position of creation, which is used as a unique identifier that
when determine whether or not a pair of structures, unions, or enums
are identical.
* accept the file name '-' to indicate that standard input is to be
used as lint1 input. That involves having lint pass the '-' through
to the cpp which preprocesses the lint1 input, and having lint1's
scanner recognize a cpp filename "" as "{standard input}".
unions, and enums are, in fact, identical. This is done by tagging
each of unnamed and untyped structure, union and enum with a unique
position of creation, which is used as a unique identifier that
when determine whether or not a pair of structures, unions, or enums
are identical.
variable declaration, in addition to within function & variable
declarations and function bodies. I think this comes close enough
to what gcc does to be considered "correct enough." Certainly, it
fixes the problem for the couple of cases where this is a problem
in our tree.
christos