> A C compiler is (at least conceptually) not an end-to-end compiler that
> receives source code and produces an executable (like e.g. Turbo Pascal
> was).

That was Turbo Pascal 3.0 only which was basically creating a COM fieformat
(hint: COM is not a fileformat, that is a plain binary). I was using
TurboPascal 3.0 on an Apple II Z-80 Softcard (made by Microsoft, and guess
what, used CP/M operating system).
>From Turbo Pascal 4.0 Borland introduced Units and therefore linkers and
libraries. That was a damn good development system by that time.

http://en.wikipedia.org/wiki/Turbo_Pascal

Tamas


On Sat, Oct 25, 2008 at 11:43 AM, Gerhard Fiedler <
lists@connectionbrazil.com> wrote:

> Olin Lathrop wrote:
>
> >> Compiler errors are not a replacement for linting.
> >
> > Why not?  Since you are running lint you obviously want to catch these
> > errors.  How would having this capability built into the compiler not
> > solve the same problem and more simply.
>
> Rather than saying "compiler errors", I think this should be "compiler
> warnings". With this substitution, I agree.
>
> >> Use a linter
> >
> > The fact that lint even exists proof of inadequate compiler.
>
> I think what you're seeing here is the Unix style of single-purpose
> applications and tool chains rather than single, integrated tools.
>
> A C compiler is (at least conceptually) not an end-to-end compiler that
> receives source code and produces an executable (like e.g. Turbo Pascal
> was). It is a tool chain that, at the minimum, includes a compiler and a
> linker and which is typically controlled by a makefile (and the make
> utility). In such a setup, adding a linter to the chain isn't anything that
> would increase the complexity.
>
> Seen from this angle, the linter's function is to make sure that everything
> is according to your coding style. And the C compiler's function is to make
> sure that everything is according to the C spec. And the linker's function
> is to make sure everything needed is there and that a proper executable can
> be created. Using the Unix application paradigm, this is not inadequate; it
> is just how things are done.
>
> Of course, many (especially Windows) setups are not like this. Make and
> makefiles are replaced by compiler-built-in smarts, the different stages of
> compiling and linking are hidden inside a single executable, the compiler
> provides a number of warnings that have nothing to do with the C spec and
> are moving towards linting... So why not build full-blown lint
> functionality into the compiler?
>
> Probably an economic decision, simply. It's not something that isn't there,
> it's just not up to the same level in compilers as it is in dedicated
> linters. It's the 80/20 rule at work: with the 20% of linting that are
> built into the better compilers, they satisfy 80% of the users. To satisfy
> the remaining 20%, they'd have to spend 5 times as much and implement the
> remaining 80% of linting -- economically not attractive :)
>
> Gerhard
>
> --
> http://www.piclist.com PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist
>



-- 
Rudonix DoubleSaver
http://www.rudonix.com
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist