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