purtill@morley.rutgers.edu (Mark Purtill) (02/06/91)
rfg@NCD.COM (Ron Guilmette) writes: >I consider it to be a fundamental part of the job of a "compiler" to >perform a good deal of "checking" on the programs (or sub-hunks of >programs) that I feed it. Placing some of the checking into a separate >tool is like inviting somebody to write crappy code. It also invites compiler suppliers to either not supply the 'lint'oid and/or charging more money for it (which means some users do without). If the checking is in the standard, this is at least less likely to happen (although I can see vendors advertising "standard compatibility" add-on programs and rubbish like that). ^.-.^ Mark Purtill purtill@dimacs.rutgers.edu (908)932-4580 (O) ((")) DIMACS, P.O. Box 1179, Rutgers U., Piscataway, NJ 08855 (908)220-6905 (H) ********** Note new area code! We are now (908) rather than (201)! **********
barmar@think.com (Barry Margolin) (02/06/91)
In article <Feb.5.16.07.07.1991.1899@morley.rutgers.edu> purtill@morley.rutgers.edu (Mark Purtill) writes: >rfg@NCD.COM (Ron Guilmette) writes: >>I consider it to be a fundamental part of the job of a "compiler" to >>perform a good deal of "checking" on the programs (or sub-hunks of >>programs) that I feed it. Placing some of the checking into a separate >>tool is like inviting somebody to write crappy code. > It also invites compiler suppliers to either not supply the >'lint'oid and/or charging more money for it (which means some users do >without). If the checking is in the standard, this is at least less >likely to happen (although I can see vendors advertising "standard >compatibility" add-on programs and rubbish like that). It is not the job of a language standard to force vendors to provide all the tools needed to implement a good programming environment. A language standard should define the language; the contract between the vendor and the user is that a program that conforms to the language spec will produce results as defined by the language spec. Market forces should be used to go further than this. If warning messages are considered a good thing, then compilers that produce lots of useful warnings should sell better than those that don't. Word of mouth, magazine reviews, etc. should be used to weed out crappy products. Even government procurements are allowed to specify requirements beyond just those in a standard. This is frequently called "quality of implementation". However, this can be taken too far. The ANSI C standard could have left many things undefined that they actually defined to result in a compiler warning. For instance, they specified that compilers must produce warnings for syntax errors. There are a few things that we have come to take for granted in compilers, and which are supported by most modern compiler-building technologies, so it is not unreasonable to specify it as part of the language. The boundary between the two areas is, of course, fuzzy. In the end, users and vendors comprising the language standardization committee will have to decide where to place it. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
jlol@REMUS.EE.BYU.EDU (Jay Lawlor) (02/06/91)
>>>>> On 5 Feb 91 21:07:09 GMT, purtill@morley.rutgers.edu (Mark Purtill) said: Mark> rfg@NCD.COM (Ron Guilmette) writes: >I consider it to be a fundamental part of the job of a "compiler" to >perform a good deal of "checking" on the programs (or sub-hunks of >programs) that I feed it. Placing some of the checking into a separate >tool is like inviting somebody to write crappy code. Mark> It also invites compiler suppliers to either not supply the Mark> 'lint'oid and/or charging more money for it (which means some users do Mark> without). If the checking is in the standard, this is at least less Mark> likely to happen (although I can see vendors advertising "standard Mark> compatibility" add-on programs and rubbish like that). Which reminds me... It really irks me when a company sells you the "default" compiler with their system and then says, "but if you want xx% better performance you should buy our super optimizing compiler." In other words, "since we have a lousy compiler that doesn't really take advantage of the machine we sold you we'd like to make it up to you by selling you something else." This could extend to other "essential" tools which should come with the system. (flame avoidance: I'm not talking about DOS machines here since nothing really "comes with the system" anyway. Also, I'm not saying a lot of companies do this but I've seen it before.) Anyway, back to the subject. I don't know if this has been mentioned but I always thought one nice feature of lint was to tell you about variables that are defined but never used. It doesn't affect your code performance or correctness but it does help clean up and improve readability, etc. Are there compilers (c++, ANSI C, whatever) which perform this function?
jbuck@galileo.berkeley.edu (Joe Buck) (02/07/91)
In article <9102060507.AA24293@ucbvax.Berkeley.EDU>, jlol@REMUS.EE.BYU.EDU (Jay Lawlor) writes: |> Anyway, back to the subject. I don't know if this has been mentioned |> but I always thought one nice feature of lint was to tell you about |> variables that are defined but never used. It doesn't affect your |> code performance or correctness but it does help clean up and improve |> readability, etc. Are there compilers (c++, ANSI C, whatever) which |> perform this function? gcc and g++ do this, if you turn on the warning. Do gcc -O -Wall or g++ -O -Wall and most of the tests that lint performs will be performed by the compiler. -- Joe Buck jbuck@galileo.berkeley.edu {uunet,ucbvax}!galileo.berkeley.edu!jbuck