Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 exptools 1/6/84; site ihnp3.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxj!ihnp4!ihnp3!dhp
From: dhp@ihnp3.UUCP (Douglas H. Price)
Newsgroups: net.lang.c
Subject: Re: Re: 6 char externs and the ANSI standard
Message-ID: <120@ihnp3.UUCP>
Date: Mon, 12-Nov-84 10:57:29 EST
Article-I.D.: ihnp3.120
Posted: Mon Nov 12 10:57:29 1984
Date-Received: Mon, 19-Nov-84 12:27:17 EST
References: <12792@sri-arpa.UUCP> <454@voder.UUCP> <1570@nsc.UUCP>
Organization: AT&T Bell Labs, Naperville, IL
Lines: 42


>In article <9477@watmath.UUCP> atbowler@watmath.UUCP (Alan T. Bowler) writes:
>
>> ... The fact remains that the loader format is the single hardest thing
>> to change on a system. ...
>
>Harumph.  That's called lack of foresight.  I seriously doubt those 3
>complete rewrites took place on a "let's rewrite the OS from scratch"
>basis.  More likely it got done piece by piece.  If, when you do one piece,
>you leave the hooks for longer names, over time you will have hooks in
>nearly everything, and the conversion is then easy.  This is proven by the
>fact that it was possible to upgrade the limit from 6 to 8.  The
>best time to do this is when you are rewriting the single hardest-to-change
>part, which is usually either the loader or the part of the OS that
>initiates tasks/programs/processes/jobs.
>
	All well and good, but manufacturers have very little interest
	in touching what already works just fine, thank-you, for their
	own software.  Why should a manufacturer risk the good-will of
	their customers by fielding a completely new version of such a
	key tool (the loader)?  Why reintroduce all of the bugs that have
	been shaken out over the life of the product?  To anticipate the
	argument, this is NOT the same as normal product enhancement.  Make
	all of the demands you like, the fact is that only new systems will
	have long symbol names, and only normal attrition will get rid of old
	systems.

>>(the suggestion about a post compiling step that remaps names
>> falls on its face on any reasonable sized program (200-400
>> routines spread over as many source files.)
>
>Why?  Don't think of it as a post-compiling step, think of it as a
>pre-linking step.  Big difference in binding times.
>
	Ever try to debug a program that has had its symbols remapped?
	The defense rests..

-- 
						Douglas H. Price
						Analysts International Corp.
						@ AT&T Bell Laboratories
						..!ihnp4!ihnp3!dhp