Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!bloom-beacon!oberon!cit-vax!ucla-cs!zen!ucbcad!ames!amdahl!oliveb!sun!gorodish!guy
From: guy%gorodish@Sun.COM (Guy Harris)
Newsgroups: comp.lang.c
Subject: Re: MAJOR ANSI C WART (my opinion, of course)
Message-ID: <31056@sun.uucp>
Date: Fri, 16-Oct-87 00:17:54 EDT
Article-I.D.: sun.31056
Posted: Fri Oct 16 00:17:54 1987
Date-Received: Sat, 17-Oct-87 17:42:09 EDT
References: <1298@wyszecki.munsell.UUCP> <1386@dataio.Data-IO.COM>
Sender: news@sun.uucp
Lines: 44

> Compiler vendors have to do a lot of work to convert K+R compilers into
> ANSI C compilers. Since they will have to do this work anyway, what's the
> big deal about fixing the linker so it will handle 32 character names?

It's not just "fixing the linker"; it may also be fixing the object file
format.  It is certainly possible to do so in *some* cases (for instance, COFF
was extended to handle long symbol names); however, I don't know how much
effort would be involved if, say, IBM wanted to extend the
OS/360-and-successors object file format.  (Assuming it hasn't already been
done.)

> I don't understand the problem that the vendors have. If the vendors don't
> have control over the linker, they can write their own.

This may be true in, say, the MS-DOS world (I get the impression that linkers
have proliferated like rabbits there); I don't know how much extra work it
would be, though, to do a new linker for OS/360-and-successors, nor do I know
how usable such a linker would be if it couldn't handle old-style object files
and libraries.

Also note that inconveniences to C programmers may not necessarily be
sufficient to get a vendor to upgrade their linker.  I don't know that all
machines are going to experience an explosion in the availability of software
just because people are more willing to write in C for that machine.

> Assume 31 char limits, and refuse to port your software to a machine if
> it only has 6 char limits. Take a stand!

This is a perfectly rational position, as long as the person holding it doesn't
take it as given that this will cause everybody to update their object file
formats.  Nobody says that *every* programmer using C *must* write to the
lowest common denominator; if you're writing software for some market where all
linkers support long names, and don't care about other markets, there's no
point in unnecessarily constraining yourself.

The people complaining about the ANSI C standard's minima here are too low
should note that the lives of many programmers (in fact, probably *most*
programmers) out there will not be affected in the least by this aspect of ANSI
C; they will continue to be able to use longer object names.  They should also
note that it is not a given that getting the ANSI C committee to raise this
minimum will cause every C implementation out there to raise *its* minimum.
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy@sun.com