External Linkage in dpANS C

[David Collier-Brown]

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