Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!usc!samsung!munnari.oz.au!bruce!goanna!ok From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) Newsgroups: comp.lang.c Subject: Re: Can lint help an ANSI-C programmer? Message-ID: <3135@goanna.cs.rmit.oz.au> Date: 3 Jun 90 06:19:21 GMT References: <6328.265D8157@puddle.fidonet.org> <1754@tkou02.enet.dec.com> Organization: Comp Sci, RMIT, Melbourne, Australia Lines: 46 In article , zuhn@umn-cs.cs.umn.edu (Zoo) writes: > >>>>> On 31 May 90 11:25:42 GMT, ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) said: > RAOK> How is an ANSI C compiler, with just one file to look at, > RAOK> going to notice that you've defined two functions with the > RAOK> same name in different files? Yes, the linker will catch > RAOK> that one, but the linker won't tell you which lines the > RAOK> definitions are on, and lint will. > Then fix your linker... I use GNU ld and it does just what you say > the linker won't do. You don't need lint to catch this. Will you kindly tell me how I can fix the linker on an Encore Multimax *without source*? Obviously a linker _could_ do this, what I said and meant is that the linkers I have to use _won't_. I learned programming on a B6700, and have never understood why other binders are less capable. But they are. If GNU ld runs on Encores, I would like to hear about it (they use COFF, even under their "BSD" version, and there are extensions to deal with sharing and other parallel-related features). What's more, even GNU ld can't report line number information that isn't _there_, and the default behaviour of cc at any rate on this system is _not_ to produce line number information. I tested this by doing cc -c last.c aoutdump -l last.o which found no line number information in last.o. Obviously, a C compiler *could* do what the Burroughs Fortran, Algol, Cobol, ESPOL, PL/I, and so on compilers did back in the 60s and leave *complete* symbol table information and complete line number information in object files as a matter of course, and linkers *could* act like the Burroughs "Binder" and check that all the references to a symbol were type-consistent. It would even be possible to have a language-specific means of checking interfile consistency despite the limitations of a linker, as Simula 67 had in the 60s and as Ada has at this day. But there is nothing in X3.159 to *force* any of this. I note that my posting listed a number of other things that lint could do for you which Zuhn has not listed Gcc/Gld as currently doing; I'll stipulate that there is no reason in principle why they _couldn't_. I'll also point out that by the time you have a compiler/linker system that _does_ do these intermodule checks, what you'll have will _be_ lint in everything but name. -- "A 7th class of programs, correct in every way, is believed to exist by a few computer scientists. However, no example could be found to include here."