6 char externs and the ANSI standard

[Alan T. Bowler [SDG]]

We all know we want long external names.  The fact remains that the
loader format is the single hardest thing to change on a system.
I know of one case where the loader (and its object format)
have survived about 20 years.  There have been 3 complete rewrites
of the operating system, but the object deck is essentially the same.
(although in one version of the operating system the limit on names
went from 6 to 8).  It took almost 10 years for even the Unix
loader to allow names longer than 7 in C programs.
    It is easy for people to say, "let the manufacturer write a new loader
that handles C's long names".  There is an implicit assumption here
that the compiler author is the manufacturer.  This is frequently
not the case.  An independant software house writing a C compiler
must make it work with the manufacturer's loader, or the compiler will
simply not sell.  Supplying another loader, is also not a viable option
we have seen this tried, and the new loader (and compiler) are dismissed
as simply an academic exercise because it fails to provide all
the baggage functionality that the old loader has accumulated over
the years.  All you can do is produce a compiler that produces
the old object deck (probably by postprocessing a more reasonable
new deck), and lobby the manufacturer for a brand new more modern
loader.  In the meantime you have to live with the 6 character limit.
(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.)  You have to use
 the manufacturers loader, and library formats).
     The best thing the ANSI committee can do is put in the line,
that says that a standard comforming program must have its external
names unique in the first 6 characters (case ignored).  The wording
needs to be done carefully, so that it is clear that a compiler
loader environment that uses longer names is also standard conforming.
I.e. it is NOT being required to consider "abcdef1" equivalent to "abcdef2".
Furthmore it is legitimate, for programmers to write long names,
but if they are not unique enough, the program may not port to some
other systems.   If this is not done C will not be implemented
on these systems, the customers will continue to use Fortran and Cobol
and the manufacturer will never see why he needs a new loader.
(Everyone programs in Fortran and Cobol don't they? :-)).
If on the other hand the standard allows the 6 character restriction,
C will be implemented on these machines, people will write programs
that use longer names, and they will try to port program that use
long names from systems that properly support them.  They will
of course get into some problems, but it will be obvious that the
problem is the loader.   This way complaints and requests for change
come to the manufacturer from the sales side, and that carrys a lot more
weight with the guys that make the decisions than the most logical
arguments from any compiler writer.
      In summary, there are a number of loaders out there with
short name restrictions.  The languages on these systems do not
use long names, and will not benefit if the loader supported long
names, so there is no customer pressure for a loader that takes
long names.  If the C standard does not recognize these systems
then C will simply not get implemented (or not get widely distributed
because it lacks the official blessing of being a standard conforming
implementation).  Since C doesn't get added to the set of languages
on the system, there is still no pressure to change the loader.
If the standard does recognize these systems, then C will get implemented and
distributed over the customer base. Since it will be obvious that fixing
the loader will make C better, this will generate pressure from the
customers to fix the loader, and the loaders will finally get fixed,
and we will finally be rid on the 6 character restriction
(and won't have to fight THIS battle on the nxt language).