Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!rutgers!princeton!allegra!ulysses!mhuxt!ihnp4!chinet!steinmetz!putnam From: putnam@steinmetz.UUCP Newsgroups: comp.lang.misc Subject: Re: Check the Arg Count Message-ID: <1067@steinmetz.steinmetz.UUCP> Date: Thu, 8-Jan-87 07:33:42 EST Article-I.D.: steinmet.1067 Posted: Thu Jan 8 07:33:42 1987 Date-Received: Fri, 9-Jan-87 06:32:50 EST References: <3214@bu-cs.BU.EDU> <4900@mimsy.UUCP> Reply-To: putnam@thuban.steinmetz.UUCP (putnam) Organization: General Electric CRD, Schenectady, NY Lines: 43 In article <4900@mimsy.UUCP> mangoe@mimsy.UUCP (Charley Wingate) writes: >You still haven't explained why lint as a processor should be logically and >functionally distinct from cc as a processor. The ONLY reason I can see for >separating them is so that you don't have to be confronted with messages >telling you that you're writng tricky or otherwise dubious code. I dont want to get into a "to lint or not to lint" fight here, but i do think that there are very good reasons to keep lint separate from cc : In a large system, lint looks at everything, and in "edit-run-think-debug..." loops, the overhead of lint is unnecessary and unhelpful. (I change a loop from "for (i=0 ; i < 100 ; i++)" to "for (i=0 ; i < 101 ; i++)", and need to re-lint the file. Absurd. I might be building something that produces C code as output, and linting it will be expensive, and will require that i build in the annotations to keep lint happy as i build the processor. This will interfere with my concentrating on the important structure of the program. I (or the people i work for) might have a modified lint with strong stylistic guidelines, or... which should be run instead. In general, i believe that it is a good idea to keep things which are logically separate, separate. Thus, i like having a c compiler which keeps the preprocessor, the compiler, the assembler, .... all distinct. In this way i can change a processor that does that step when i need to, omit steps (where that makes sense), or add additional steps (like editing the assembler). Most of the time, i do not do this, but i have needed to in the past, and found difficulties with compilers that would not let me get to intermediate stages. (I needed to get at the assembler output to do something once, and the only way to do it was to use the flag that produced an assembler listing (interleaved with the code, and the results of the assembly!), then edit the listing to produce usable assembler - and that didnt even assemble correctly without more work.) Keep separate parts separate! Wasnt this part of the "Unix(tm) Philosophy"? -- O -- jefu tell me all about -- UUCP: steinmetz!putnam Anna Livia! I want to hear all.... -- ARPA: putnam@GE-CRD