[net.lang.c] Non-reentrant code generated by

jab@uokvax.UUCP (09/21/84)

/***** 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

gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (09/24/84)

Actually, pcc, lint, cxref, cflow, etc. all use the same YACC grammar
for C now (speaking about UNIX System V, don't know the others), also
most of the "machine independent" part of PCC is shared.

I think part of lint's permissiveness on some systems results from
excessive sharing of code with PCC, not insufficient sharing.  The C
compilers typically convert all types to combinations of basic types
very early on, so that the distinction between "int" and "short" or
"long" (depending on your machine) has been effaced too soon.  Later
versions of the compiler seem to be better about this but still not
perfect.