lint on V.3

[Keith Waclena]

In article <1123 at virtech.UUCP>, cpcahil at virtech (Conor P. Cahill) writes:
"In article <1394 at redsox.bsw.com>, campbell at redsox.bsw.com (Larry Campbell) writes:
"> 
"> I have run into the same EXTREMELY IRRITATING problem with Interactive 386/ix
"> V2.0.1 (derived from SVR3.2).  When I called Interactive to complain, they
"> said "how big is your program" and when I said "oh, maybe, 75K lines of code"
"> they sort of fell over backwards and said "oh, wow, man, that's huge".
"> Gimme a break.  750K lines is rather big.  75K lines is pretty humdrum stuff.
"> 
"
"I too would fall over backwards if you told me that ONE of your source files
"is 75K lines of code.
"
"However, I think that the system programs (cc, lint, ld, etc) should not
"have any hard-coded limits on the number of lines, number of symbols, 
"or any other such entity.

I've had to recompile (if memory serves) cc (case labels), cpp
(symbols), and as (symbols) on System V.2 machines to increase hard
coded limits.  I agree that this is *extremely* annoying.  A dynamic
approach to memory allocation would be best, but it seems that one
could at least expect a command line option to set the size of crucial
arrays.

I also think that 75K of code for one source file (if that's what
Larry meant) is huge, but let's not forget that C (and any other
language) may well be the *object code* of some higher level compiler;
think of lex, yacc, C++, and the Kyoto Common Lisp compiler to name
just a few.  The output of programs like these can sometimes be huge.

						Keith

--
Keith WACLENA                             keith at curry.uchicago.edu
GLS / TIRA / U of Chicago                 keith%curry at uchimvs1.bitnet
1100 E.57th.St Chi IL 60637 USA           ...!uunet!curry.uchicago.edu!keith

"Maybe one day the computers of the world will one by one be replaced
by birds until there are no computers left -- only birds!  Wouldn't
that be a beautiful world?"                             Raymond Smullyan