linkers - next frontier?

[Henry Spencer]

Dick Dunn observes:

    (This was in reference to the developing C standard.)  I agree that it's
    about time to tackle problems with lame-brain linkers!  Short names is only
    one of a whole raft of problems we've got with <most> present-day linkers.

And Larry West likewise:

    The other point which bothers me, even more, is the limitation of
    six significant characters in external names.   It seems to me that
    the cost of converting a few linkers from 6 characters to some
    larger number (say, 16 -- even 10 or 12 would be a vast improvement)
    is much less than the cost of having programmers figure out
    meaningful six-character names to use.   There aren't really that
    many informative identifiers with six characters -- maybe a few
    hundred at most.   Add to the cost of figuring out a group of
    6-character identifiers (also not conflicting with any system
    call or subroutine name) the cost of trying to decipher such
    things.
    
    And who really has 6-char-max linkers that they plan to support,
    unchanged, for the next ten years?   I've never come accross any.

The problem is that most of these deficiencies lie not with the *linkers*,
but with the *object* *module* *formats*.  Changing those would require
changing every compiler -- remember, in most non-Unix environments the
compilers generate object code directly -- and this is the job that nobody
can face.  Do you really want to tackle the job of fixing the output module
of every compiler ever written for the 360?  Sure, it could be done, but
the problems are monumental and the conversion period would be agonizing
for the customers.  Many of them, with good reason, would simply refuse
to cooperate.  The problem really is unfixable in the context of old systems.
The best we can do is to make sure that *new* systems do it right.
-- 
				Henry Spencer @ U of Toronto Zoology
				{allegra,ihnp4,linus,decvax}!utzoo!henry