Lint Libraries

[Spencer W. Thomas]

>In article <331 at isucs1.UUCP>, russell at isucs1.UUCP writes:
>>                                                . . . I have yet to find a
>> way to convert the lint library to a human readable form (like has been done
>> to the standard libraries).

>
>The readable lint libraries (e.g., /usr/lib/llib-lc or /usr/lib/llib-lc.c)
>aren't created from the binaries; the binaries are created from the
>readable versions.

This is close, and may actually be the case for llib-lc.  However, lint
has this neat option (on 4.2, anyway) that lets you say
	lint -Cfoo *.c
and create the llib-lfoo library.  The problem is that error
diagnositics that refer to the library on future lint runs are sort of
useless (the line numbers, anyway).  It would be really nice to get a
human readable form from the binary form, just for the purpose of
interpreting the diagnostics, anyway.  The problem is, you can't do it
(at least, given just the llib-lfoo file).  The type names have all been
hashed away -- all the llib-lfoo file tells you for structures is the
size and a hashed identifier.  This allows lint to compare for the same
structure, but it can't reconstruct the names.  You could build a
llib-lfoo.c file (I think), but the names would have to be generated
ones :-(g0001, g0002, ...)  I looked at this for a couple of days some
time ago, but gave it up as a loss.  Instead I use a Gosling emacs
function that turns my .c files into a llib-lfoo.c file, then use lint
-C on that.  This relies, of course, on certain code formatting
practices, and is not foolproof.  There ought to be some way to hack the
C parser to do it (Hey!  now there's a use for the C grammar that was
posted to the net recently.)

-- 
=Spencer   ({ihnp4,decvax}!utah-cs!thomas, thomas at utah-cs.ARPA)
	"You don't get to choose how you're going to die.  Or when.
	 You can only decide how you're going to live." Joan Baez