Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!henry
From: henry@utzoo.UUCP (Henry Spencer)
Newsgroups: net.lang.c
Subject: Re: C not LALR(1) & compiler bugs
Message-ID: <6355@utzoo.UUCP>
Date: Tue, 4-Feb-86 19:20:05 EST
Article-I.D.: utzoo.6355
Posted: Tue Feb  4 19:20:05 1986
Date-Received: Tue, 4-Feb-86 19:20:05 EST
References: <10200035@ada-uts.UUCP>, <10200037@ada-uts.UUCP>
Organization: U of Toronto Zoology
Lines: 56

> ... I simply don't like being told in K&R and H&S that
> if I want my programs to be portable, I should ensure that the first
> six characters of all of my external id's are different, ignoring case,
> so that I can port it to a Honeywell 6000.  Is it really crucial for
> the compiler generated code to conform to the limitations of ALL
> linkers and loaders?

Do you want your programs to be portable or not?  The fewer assumptions
you make about the environment they will run in, the more portable they
will be.  Six-characters-monocase is a rather extreme restriction (although
there are worse linkers on some real systems!), but code that conforms to
it will run on almost anything.  Once you go beyond 8 characters or so of
significance, the number of machines it will run on drops *sharply*.  Do
you care about portability or not?

> ... I should either get a modern linker or worry about
> mapping identifiers in the object code MYSELF -- it really isn't
> hard.

Tell that to an IBM user, who doesn't *want* to write his own linker.
Many people have to live with support software they do not control...
and those who do control such software often are reluctant to invest the
enormous efforts that would be needed to support two incompatible versions.
Whether this is *right* or not, it is a *fact*.  Nor are such problems
trivial to solve, especially when maintenance and updates are considered;
many people who are faced with software containing unportable constructs
like long identifiers eventually give up on it.  Again, whether this is
*right* or not, it is a *fact*:  if your code relies on long identifiers,
there are many potential users who will never be able to run it.

> If anybody can think of ANY reason for limiting the number of significant
> characters of non-external identifiers to 8, I'd be honestly interested
> in hearing it -- these identifiers don't even exist after compilation!

Here the arguments are weaker; object-file formats and linkers don't enter
the picture.  But for the present, the problem remains:  many people have
compilers which observe such limits, and are not free to change.  *This*
problem should eventually go away, since the ANSI drafts all mandate rather
longer minima for internal identifiers.  Meanwhile, again, many potential
users will be unable to run your software if you make it gratuitously
unportable by using identifiers not unique in the first 8.

> ... come on, should
> you, in your language definition, make such silly concessions simply
> to ease the construction of compilers for your language?  ...

A sound point for new languages.  C is not a new language.  Life would be
a lot simpler if C had mandated arbitrary-length identifiers from the start,
but it didn't happen that way.  IT DID NOT HAPPEN THAT WAY.  That is the
situation; whether you like it or not doesn't change it.  You can either
live with it, and make your software portable, or refuse to accept it, and
make your software unportable.  A disagreeable choice, but that's the way
it is.
-- 
				Henry Spencer @ U of Toronto Zoology
				{allegra,ihnp4,linus,decvax}!utzoo!henry