Path: utzoo!utgpu!water!watmath!clyde!ima!haddock!karl
From: karl@haddock.ISC.COM (Karl Heuer)
Newsgroups: comp.lang.c
Subject: Re: C Compiler bugs
Message-ID: <4427@haddock.ISC.COM>
Date: 7 Jun 88 00:07:32 GMT
References: <15085@tut.cis.ohio-state.edu> <4421@haddock.ISC.COM> <15202@tut.cis.ohio-state.edu>
Reply-To: karl@haddock.ima.isc.com (Karl Heuer)
Organization: Interactive Systems, Boston
Lines: 24

In article <15202@tut.cis.ohio-state.edu> lvc@tut.cis.ohio-state.edu (Lawrence V. Cipriani) writes:
>In article <4421@haddock.ISC.COM> karl@haddock.ima.isc.com (Karl Heuer) writes:
>>In article <15085@tut.cis.ohio-state.edu> lvc@tut.cis.ohio-state.edu (Lawrence V. Cipriani) writes:
>	...
>>>	struct blob { int a, b, c; } /* missing ; */
>>>	main(argc, argv) ...
>>Why should it be considered a "compiler bug" when a syntactically correct
>>program containing a user bug dumps core?  [Fix it in lint]
>
>It certainly would be appropriate for lint, but don't you think this is
>a stupid thing for a compiler to allow?

Yes, but the general problem of mismatched declarations requires cross-file
checking, which has traditionally been in the jurisdiction of lint.  At least
until type-checking loaders become popular.  Misdeclared main() is just one
instance of the problem.

>... also not every implementation of C is accompanied by lint.

I've said it before (usually in Pascal-vs-C discussions): a C compiler
consists of two parts, traditionally called cc and lint.  A vendor who doesn't
supply a lint equivalent is only selling half a C compiler.

Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint