Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!haven!adm!cmcl2!kramden.acf.nyu.edu!brnstnd
From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
Newsgroups: comp.lang.misc
Subject: Re: Answers, Chapter 1: TeX
Message-ID: <11854:Nov723:28:2490@kramden.acf.nyu.edu>
Date: 7 Nov 90 23:28:24 GMT
References: <6555:Nov720:35:2690@kramden.acf.nyu.edu> <5224@lanl.gov>
Organization: IR
Lines: 24

In article <5224@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
> If so, it must
> be clear to everyone that there may not _be_ a .c file corresponding
> to the .h file - the code might be proprietary, the vendor sent the
> .h file and the .o file and nothing else.  So, how does the compiler
> check at compile time when it "gets around to that .c file" which
> doesn't even exist?

As I said, the compiler checks the validity of the .h file against each
c file when it compiles the .c file. If the vendor has sent along a .o,
then obviously the compiler has compiled the vendor's .c, so it had the
chance to check at that point.

You started this subthread by saying that the loader should check
prototype matches and the compiler should not.

You may be right about the first, but AT&T's C++ uses the same solution,
and it's an awful botch. If you ever make a prototyping error in it,
you'll see why.

You are absolutely wrong in saying that the compiler should not check
prototypes. I don't think you'll find anyone to agree with you on that.

---Dan