mrd@sun.soe.clarkson.edu (Michael DeCorte) (09/01/89)
Does anybody know what would cause lint to print "To many names" or more important how to fix this? Happens to be a Sys VR3 on a motoroloa vme147 thanks -- Michael DeCorte // H215-546-0497 W386-8164 Fax386-8252 // mrd@clutx.bitnet 2300 Naudain St. "H", Phil, PA 19146 // mrd@sun.soe.clarkson.edu --------------------------------------------------------------------------- Clarkson Archive Server // commands = help, index, send, path archive-server@sun.soe.clarkson.edu archive-server%sun.soe.clarkson.edu@omnigate.bitnet dumb1!dumb2!dumb3!smart!sun.soe.clarkson.edu!archive-server ---------------------------------------------------------------------------
campbell@redsox.bsw.com (Larry Campbell) (09/03/89)
In article <MRD.89Sep1110612@sun.clarkson.edu> mrd@sun.soe.clarkson.edu (Michael DeCorte) writes:
-Does anybody know what would cause lint to print
-"To many names"
-or more important how to fix this?
I suspect the reason is that some IDIOT built lint with a fixed-size array
somewhere, and made the size so small that only toy programs can be linted.
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 think your only recourse (and mine) is to complain loudly to our respective
software suppliers to recompile lint with a reasonably sized array. And
reasonable means (listen up, spuds!) it had better be able to handle over
500K lines of code, with over 100K distinct names.
--
Larry Campbell The Boston Software Works, Inc.
campbell@bsw.com 120 Fulton Street
wjh12!redsox!campbell Boston, MA 02146cpcahil@virtech.UUCP (Conor P. Cahill) (09/03/89)
In article <1394@redsox.bsw.com>, campbell@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. That is a HUMONGOUS ?sp? amount of code to be in one source file and probably causes great headaches to support. How long does it take the editor to start up? 5 minutes? 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. They should be able to malloc() whatever they need and should only have a problem when the malloc() fails. -- +-----------------------------------------------------------------------+ | Conor P. Cahill uunet!virtech!cpcahil 703-430-9247 ! | Virtual Technologies Inc., P. O. Box 876, Sterling, VA 22170 | +-----------------------------------------------------------------------+
blm@6sigma.UUCP (Brian Matthews) (09/04/89)
In article <1123@virtech.UUCP> cpcahil@virtech.UUCP (Conor P. Cahill) writes: |In article <1394@redsox.bsw.com>, campbell@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. That is a HUMONGOUS ?sp? amount of code to be in |one source file and probably causes great headaches to support. Uhm, I don't see anywhere in Larry's posting where he says he has 75K lines of code IN ONE SOURCE FILE. That would be a lot, but 75K lines in a bunch of source files isn't all that much. |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. They should be able to malloc() whatever they |need and should only have a problem when the malloc() fails. I don't know if I'd call cc, lint, etc. "system programs", but I agree with your comment that they shouldn't have hard-coded limits on anything. At my previous job, I supported the compiler (which was standard pcc2 based stuff), and it was filled with arrays instead of using malloc (which meant one of my support jobs was to recompile the compiler after defining bigger array sizes :-) Unfortunately, this nastiness came straight from AT&T (as I suspect does Larry's compiler), so you may be able to get your vendor to recompile with larger limits, but you probably won't be able to get them to do the job right and replace the arrays with mallocs. Heavy sigh. -- Brian L. Matthews blm@6sigma.UUCP Six Sigma CASE, Inc. +1 206 854 6578 PO Box 40316, Bellevue, WA 98004
keith@curry.uchicago.edu (Keith Waclena) (09/06/89)
In article <1123@virtech.UUCP>, cpcahil@virtech (Conor P. Cahill) writes: "In article <1394@redsox.bsw.com>, campbell@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@curry.uchicago.edu GLS / TIRA / U of Chicago keith%curry@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