Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!rosevax!rose3!dan
From: dan@rose3.Rosemount.COM (Dan Messinger)
Newsgroups: comp.lang.c
Subject: Re: MAJOR ANSI C FLAW (my opinion, of course)
Message-ID: <292@rose3.Rosemount.COM>
Date: Wed, 14-Oct-87 09:57:45 EDT
Article-I.D.: rose3.292
Posted: Wed Oct 14 09:57:45 1987
Date-Received: Sat, 17-Oct-87 09:57:09 EDT
References: <1132@gilsys.UUCP> <1246@bsu-cs.UUCP> <6543@brl-smoke.ARPA> <104@aimt.UUCP>
Reply-To: dan@rose3.UUCP (Dan Messinger)
Organization: Rosemount Inc., Burnsville, MN
Lines: 52

(no flames intended, I'm just answering his question)

In article <104@aimt.UUCP> breck@aimt.UUCP (Robert Breckinridge Beatie) writes:
>Hmmm...  why is a 6 character limit necessary in any environment?  I'm not
>necessarily disagreeing with you.  But I am curious.

Because the compiler is not in control of the situation.

Consider what has to be done to a C source file to get it to executable
binary.  What does the average Unix C compiler produce?  Assembly!  So
you need a new assembler that can handle long external names, too.

And what does the assembler produce?  An object file.  You need to redefine
the format of the object files to have space to longer identifiers.

The object files are feed to a linker.  You need a new linker that uses
the new object file format.   The linker also searches a bunch of libraries.
You need all new libraries that are in the object file format.

Now this linker was used with compilers other than the C compiler.  What
happens to those Pascal and Fortran programs?  Better keep the old linker
around for them.  And then there are the little assembly routines that you
wrote that are linked into those Pascal and Fortran programs.  Can't
use the new assembler on those, since the old linker can't handle the new
object file format.  Better keep the old assembler around too.  My, this
is getting messy!

And now its time to debug your new C program.  Oops!  That fancy symbolic
debugger that you had can't handle these new long names.  And you want
to maintain your own library of routines?  Ar knows a little about the
object format so that it can make symbol tables for the linker (depends
on your Unix version).  The list goes on...

(Question:  The symbol section of the executable will need to be changed,
too.  Is there anything in the kernal that would choke if the format
of the symbol table changed?)

In summary, it takes far more than a new version of cc to get longer
external identifiers.  It a matter of momentum (and profits).  There is
a LOT of software that needs to be changed on the ol' PDP-11 to increase
the external id size.  Do you know of any software houses that want to
develope all that software, knowing that there are a fixed number of PDP-11s
in the world, and that number is getting smaller?

>Well, isn't portability the reason we need a standard in the first place?
>A standard that programmers are *strongly* tempted to disregard seems to be
>of little, if any, use.

A standard is useless if it can't be attained at all.

Dan Messinger
dan@rose3.rosemount.com