Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!usc!ginosko!husc6!ogccse!blake!uw-beaver!sumax!polari!6sigma!blm From: blm@6sigma.UUCP (Brian Matthews) Newsgroups: comp.unix.wizards Subject: Re: lint on V.3 Message-ID: <282@6sigma.UUCP> Date: 4 Sep 89 01:46:01 GMT References: <1394@redsox.bsw.com> <1123@virtech.UUCP> Reply-To: blm@6sigma.UUCP (Brian Matthews) Organization: Six Sigma CASE, Inc. Lines: 37 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