External Linkage in dpANS C
David Collier-Brown
daveb at geaclib.UUCP
Fri Jan 6 11:42:58 AEST 1989
In article <1339 at vsi1.COM> bitbug at vicom.COM (James Buster) writes:
|6. If required, why should companies with ancient linker technology
| force me to use such ancient technology, or why can't they use 80s
| linker technology?
>From article <9274 at smoke.BRL.MIL>, by gwyn at smoke.BRL.MIL (Doug Gwyn ):>
| It's not necessarily the compiler vendors who are responsible
| for the restrictions. Some old operating systems are too hard
| (read: traumatic) to change, and until there are enough "modern"
| users of those systems, the operating system vendor cannot
| justify making the effort. To do so simply to advertise
| conformance to the C standard would not be considered good
| enough reason, and requiring more in the standard would simply
| result in fewer conforming implementations -- not better linkers.
| That would be a disservice to C programmers.
True, and very annoying to clients of the linker-suppliers!
However, even **very** old linkers are relatively easy to bring up
to date as long as one can still find the source. One defines a new
record format (I wasn't kidding when I said very old) for long
names, and makes it optional in release N of the operating system.
In release N+2, you produce warnings about each use of the old
format. In N+3 you produce error messages. In N+5 you drop support.
Please note that by N+5, version N of the OS is out of support too!
This takes about 3-4 years, you realize, but it does work. One of
my previous employers did it with near-nil angst from their users.
The chap who had to figure out how the linker worked hated the idea,
though (1 man, about 3 weeks).
--dave (I should put this in my "common answers" database (;-)) c-b
--
David Collier-Brown. | yunexus!lethe!dave
Interleaf Canada Inc. |
1550 Enterprise Rd. | He's so smart he's dumb.
Mississauga, Ontario | --Joyce C-B
More information about the Comp.std.c
mailing list