Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!eecae!tank!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.lang.c
Subject: Re: Question about linking files
Message-ID: <16541@mimsy.UUCP>
Date: 26 Mar 89 05:57:14 GMT
References: <18925@iuvax.cs.indiana.edu>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 33

In article <18925@iuvax.cs.indiana.edu> bobmon@iuvax.cs.indiana.edu
(RAMontante) writes:
>... a couple of people are saying that this isn't (TurobC/MSC/whoever)'s
>fault, because C requires that all routines (all symbols, maybe?) in a
>file be linked in if any of them are.

Given that the pANS does not have the concept of a `library', or
even of `separate compilation', this is clearly false.  It is, however,
difficult to tell which of several code and/or data sections may
be required.  Consider, for instance, the following:

	static void a(), b();
	static void (*table)[2] = { a, b };

	entry_point(int n) { go(&table[0], n); }

	static void go(void (**tab)(), int n) {
		(*tab[n])();	/* this calls either a() or b() */
	}

	static void a() { (void) printf("a called\n"); }
	static void b() { (void) printf("b called\n"); }

It is not possible to tell, at compile time, which of `a' and `b' will
be called.  If `n' is deleted from entry_point(), and we call `go' with
0, b() can be elided.  Discovering this is quite difficult.  More
generally, if the link format uses offsets to locations that can be
resolved at compile time (such as from entry_point() to go(), if the
machine supports pc-relative calls), there may be insufficient
information in the object files.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris