1lint is divided into 3 separate programs: lint, lint1, and
2lint2 (the latter two programs reside in /usr/libexec).
3
4lint calls /usr/libexec/cpp to preprocess the program, then passes
5the output to lint1, which does most of the work. lint1 then outputs
6a .ln file, which is parsed by lint2 to do more holistic checks. all
7of this is driven by /usr/bin/lint, which is like a wrapper program.
8
9lint1 implements its own C parser.  it is incapable of parsing some
10weird gcc things, such as __attribute__ and so on. OpenBSD's source
11tree already does a good job of removing gcc'isms when parsers other
12than gcc are detected.
13
14lint1 keeps a symbol table for the current context, which always
15includes global symbols for the current translation unit, as well as
16locals (inside a function definition). When it parses a function
17definition, it pushes a symbol table context onto the stack, and
18then pops it off when the function definition ends.
19
20lint1 does the vast majority of its checks one expression at a time.
21It uses the symbol table (which contains types of symbols) and almost
22nothing else when doing type conversions. All of the checks happen at
23parse time. lint1 does not really build an abstract syntax tree (AST)
24to represent the entire program; it only keeps track of the symbols
25in the current context, and some minimal information about the types
26of enclosing control blocks (loops, switch statements, etc). When lint1
27is finished parsing an expression, you will not see any more warnings
28regarding that expression.
29
30$OpenBSD: README,v 1.2 2007/09/24 19:56:34 jmc Exp $
31