Non-reentrant code generated by

[jab at uokvax.UUCP]

/***** uokvax:net.lang.c / elsie!ado /  9:32 pm  Sep 18, 1984 */
Let's try for a lint trap that everyone can agree on.

Perhaps the long run thing to do is change "lint" so that you can ask
for different degrees of portability checking.  "lint -P V.2", "lint -P V",
"lint -P III", "lint -P 7", "lint -P 6", "lint -P 5"...?
/* ---------- */

While we're at it, let's have some way to have it be picky about what
can be stuffed into an "int". At the present, the following line of
code
	int i = 123456;
which is non-portable ("int" must have at least 18 bits, if I count
correctly), doesn't get flagged on the versions of lint that use 32-bit
"int", and dies on versions of lint that use 16-bit "int". You can see the
problem, but there needs to be a restructing of the "lint" code to pull it
a little further from the compiler itself.

A nice way to start might be to put the "yacc" input for the C compiler
somewhere in "/usr/lib" and have "cc", "lint", the flow analyzers your
version has, "cb", and the like, ALL USE THIS FILE. "Too tough," you say.
That way, we could possibly localize the "syntax-specific" parts of these
programs and let "lint" approach the input program as something to be
analyzed, not something to be compiled. (Since it's largely pass one of the
compiler, this might get rid of problems.)

Comments? Flames? (The "/usr/lib" idea actually belongs to uokvax!emjej,
but is a nice start. (In fact, putting the "tree" code from the compiler
in a library would make the source for "f77", "pcc", and the Berkeley Pascal
shrink a great deal, wouldn't it?))

	Jeff Bowles