- Lackwit uses type inference to analyze a C program. (actually, it converts
  C into a little language that supports their types, and analyzes that...)
- Every variable is, initially, a distinct type.  As the tool scans
  code, it infers which variables must be the same type, based on some
  simple rules.  For example:
	int a;
	int *b;
  	a = *b;
  The two ints are inially distinct types, but because one is assigned
  to the other, Lackwit infers they must be compatible.
- It can handle polymorphic functions, because it keeps the function's 
  signature separate from the function's use.  In their trivial example
  (Lackwit, pg 4), the 'c' and 'd ' arguments to 'f' are related.  This 
  means that in the first call to 'f', 't1' and 'q' are related, and in
  the second call 'r' and 's' are related.  However, 'r' and 't1' are not
  related, even though they're passed as the same argument to the same
  function.
- The type inference rules are pretty simple, and we've seen them already.
  They note that they're helpless to infer types across a cast.

- They also tack on some bug-finding ability by augmenting the types. 
  They keep track of whether a variable has been read from and written to,
  and whether a pointer has been set to some heap memory and freed.  It's 
  easy, because they're just changing the type from "int-alpha" to 
  "unallocated-read-int-alpha"
- This can be used to find variables that are uninitialized or never read
  or memory leaks, but it's pretty rudimentary.  Lackwit is flow-insensitive
  so all it can find is must-be-uninitialized, must-be-leaking, etc.

- The program overview that Lackwit produces is useful for finding abstraction
  problems.  In their fig 6 (pg 7), the "map_mgr_process_image" function is
  accessing *(map_manager_global->cur_veh), which is an abstract vehicle 
  pointer.  The "veh" functions are the only ones that should look at cur_veh,
  so you can do OO C without that peskey ++.