What's the theory behind lint(1)?

I want a reference to something more-or-less authoritative, which
addresses such questions as:
1. What is the complete list of diagnostics lint(1) considers?
2. Is there an ANSI standard for lint(1)?
3. Does the ANSI standard for C compilers dictate what they
        do on reception of erroneous input? ... suspect input?
4. How do compiler implementers decide which warnings to put
        in cc and which in lint(1)? The only responses to this that
        I know are variations on
        a. "... well, it's always been that way", and
        b. "gag, cough, a language incriminates itself when
                its compiler doesn't check for all the errors
                that it can. Ecrasez C, vive Pascal!"
        Does the academic community have anything more sophisticated
        to say?


My object in this is rather diffuse. I'm a big believer in the utility of
defining special-purpose languages, and also in automating testing and
error-checking; I conclude, then, that my special-purpose language
processors need to check for lots of errors. What have gen- erations of
lint(1)-writers learned about this task? What kinds of errors do
programmers generate? I incline to the practical; I care more about
flagging the kinds of typing errors lots of folks allow to creep in, than
a sophisticated data-flow analyzer that catches an absurdity that no one
ever enters anyway.


I've thought of three likely locations for the sort of document I'm
searching:
1. the comments to gnu sources or associated documents (I'm very
        naive about gnu--is this a good place to look?);
2. ANSI standards;
3. compiler theory texts.


Pointers, anyone?
--
Cameron Laird +1 713-579-4613
cl@lgc.com (cl%lgc.com@uunet.uu.net) +1 713-996-8546
[The answers to questions 2 and 3 are both "no", the other two are harder to
answer. Other than agreeing that yacc parses tend to give lousy diagnostics,
I haven't seen a lot of consensus in the error department. -John]
--

Return to the comp.compilers page.
Search the comp.compilers archives again.