Path: utzoo!attcan!uunet!husc6!bloom-beacon!bu-cs!purdue!i.cc.purdue.edu!j.cc.purdue.edu!pur-ee!iuvax!bsu-cs!dhesi
From: dhesi@bsu-cs.UUCP (Rahul Dhesi)
Newsgroups: comp.lang.c
Subject: handling long externs with a post-processor
Keywords: was Re: "Numerical Recipes in C" is nonport
Message-ID: <4162@bsu-cs.UUCP>
Date: 1 Oct 88 03:17:33 GMT
References: <5162@hoptoad.uucp> <225800072@uxe.cso.uiuc.edu> <4071@bsu-cs.UUCP> <1988Sep24.212346.26591@utzoo.uucp> <4111@bsu-cs.UUCP> <1988Sep29.185014.29260@utzoo.uucp>
Reply-To: dhesi@bsu-cs.UUCP (Rahul Dhesi)
Organization: CS Dept, Ball St U, Muncie, Indiana
Lines: 40
Summary:

In article <1988Sep29.185014.29260@utzoo.uucp> henry@utzoo.uucp (Henry
Spencer) writes:
(about my proposal that a custom port-processor be used to
shorten long external names)

>And the
>postprocessor has to scan all the libraries, to prevent name conflicts
>with them.  And the object modules and libraries can't be postprocessed
>until linking time.  How, precisely, is this different from defining a
>new object-module format and writing a new linker?

We are assuming that the standard system linker can't handle long
names, so the standard libraries will only contain short (6-char or
less) symbols.  Therefore no special processing is needed for the
libraries.

My proposal does assume a new object-module format, one that contains
long symbols.  The post-processor does no linking.  It simply takes
each object custom-format object module from the C compiler and
translates it to a system-format object module.

It is possible for the post-processor to take a long symbol and convert
it to a short symbol that conflicts with a symbol already in a
library.  There are ways of preventing this.

If a naming scheme can be found that guarantees the creation of names
not already in any standard library, the problem is solved.  At the
very least, given a list of names reserved by ANSI, it should be
possible to avoid conflicts with names of standard C functions.

If no such naming scheme is possible, users of the system (programming
in any language) are already in serious trouble, since they can never
be sure that one of their global symbols won't conflict with a library
symbol.  But we can still handle this situation.  The post-processor
can be run once each time the system libraries are updated, to scan
them and make a master list of all symbols in these libraries.  Then,
each time the user's object modules are processed, the post-processor
avoids using symbols that are already in this master list.
-- 
Rahul Dhesi         UUCP:  <backbones>!{iuvax,pur-ee}!bsu-cs!dhesi