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: comp.lang.c
Subject: Re: MAJOR ANSI C FLAW (my opinion, of course)
Message-ID: <8781@utzoo.UUCP>
Date: Fri, 16-Oct-87 15:11:58 EDT
Article-I.D.: utzoo.8781
Posted: Fri Oct 16 15:11:58 1987
Date-Received: Fri, 16-Oct-87 15:11:58 EDT
References: <1298@wyszecki.munsell.UUCP>
Organization: U of Toronto Zoology
Lines: 63

> ... Companies with compilers/linkers that couldn't handle
> this limit would have to fix them.  So what?  If I had to guess, most of
> this obsolete software is owned by very large companies like IBM, DEC,
> HP, PRIME, etc.  These companies have large resources ($$$ and people),
> and they also sell a lot of systems/software. They therefore have a large
> incentive to fix their obsolete software, and the resources to do it.

Large companies did not get to be large by wasting money.  The first thing
that will occur to people at those companies is "how much will it cost us
if we simply ignore this silly standard?".

Note also that those companies, as major C users, legitimately and properly
have considerable say in the standard's development.

The odds are good that the companies in question will eventually get their
act together and do something about the problem.  However, trying to dragoon
them into doing so as a crash project by writing standards that require it
is very poor strategy; it may even delay the day when the 6-character rule
can go away.  That day will not be soon in any case; there is too much
inertia from massive customer bases.  Very large companies tend to have very
large commitments to support what they've done in the past.

> What is better?  Having a few companies with large resources and a large
> potential payback fix a few compilers/linkers, or have the entire rest of
> the C community rewrite many millions of lines of C?

Rewrite millions of lines of C?!?  What on Earth are you talking about?
C that does not observe the 6-character rule is *already* unportable, which
is about all that violating the standard implies.  None of *my* code needs
rewriting, and not all that much of the more sensibly-written code in the
world needs it either.  In any case, the "rewriting", when needed, can be
entirely mechanized via the preprocessor.

> Give me a break!  How hard is it to make an existing compiler/linker
> accept longer names?  If it isn't just changing the line
>         #define MAX_EXTERN_LEN  6
> to
>         #define MAX_EXTERN_LEN  32
> then the company that wrote that software deserves to be screwed, not
> the rest of the C community.

First you have to change that line in *all* your compilers and *all* your
utilities that manipulate object files, and then recompile them all.  That's
the easy part.  Then you have to make all the object-file-manipulating
programs understand both old and new format, because there will always be
old-format files lurking in some obscure corner of the world.  Then you
have to get those two-format programs out to every last customer who might
ever see a new-format object module.  Then you have to warn the independent
software suppliers and convince them to update *their* programs similarly.
*Then*, finally, you can start shipping the new compilers.  Fifteen or
twenty years later, you can perhaps think about dropping support for the
old format (for which you will be vilified by a substantial number of
customers, by the way, even then).

*FLAME ON*
If your cavalier disregard for compatibility and promises of continued
support, and your total lack of understanding of the difficulty of making
such a change over a large customer base, are at all typical of your
company, remind me never to buy anything from Eikonix.
*FLAME OFF*
-- 
"Mir" means "peace", as in           |  Henry Spencer @ U of Toronto Zoology
"the war is over; we've won".        | {allegra,ihnp4,decvax,utai}!utzoo!henry