Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83 (MC840302); site mcvax.UUCP
Path: utzoo!linus!philabs!cmcl2!seismo!mcvax!aeb
From: aeb@mcvax.UUCP (Andries Brouwer)
Newsgroups: net.sources,net.unix-wizards,net.lang.c
Subject: Re: long names in 'C' programs
Message-ID: <668@mcvax.UUCP>
Date: Mon, 20-May-85 10:31:27 EDT
Article-I.D.: mcvax.668
Posted: Mon May 20 10:31:27 1985
Date-Received: Tue, 21-May-85 05:09:23 EDT
References: <476@aicchi.UUCP>
Reply-To: aeb@mcvax.UUCP (Andries Brouwer)
Distribution: net
Organization: CWI, Amsterdam
Lines: 48
Xref: linus net.sources:2586 net.unix-wizards:10449 net.lang.c:4749

In article <476@aicchi.UUCP> ignatz@aicchi.UUCP (Ihnat) writes:
>
>If you insist on making 'C' programs look like COBOL by using
>32,767 character names, the *very* least you can do is make the
>damn things unique in the first 7 characters, OK?
>
>This long-name-chauvinism is annoying enough in sources posted to
>net.sources, but now I'm running into it in sources for paying business
>purposes, and it's, frankly, intolerable.
>
>One of the greatest assets of 'C' is its great degree of portability.
>But there are tens of thousands of binary-license 'C' compilers out there.
>These people don't have the freedom to modify their compiler; and when
>they pay some outside joker to write something in 'C', and he/she writes
>it with 15-character variable names that are only unique in the last 2
>characters because "compilers should be able to handle it, and it's
>conceptually desirable", or some such drivel, they can't regenerate it
>on their system.  What then?  Yep.  They pay twice, to have someone else
>fix the code.

Yes, that is what happens if you meet such a program once a year.
But now suppose you got such a program every week. Wouldnt you
instead buy a better compiler/loader?

It is reasonable to expect that new compilers accept programs that were
written long ago, but it would prevent all progress if one required
that new programs not use any features that were introduced into the
language in the past ten years.
	("My compiler cannot handle two-dimensional arrays of structures";
	"mine barfs on unsigned bit fields"; "mine doesnt like functions
	returning structures"; "mine dumps core on long int cases in a switch";
	"mine cannot evaluate arithmetic expresssions with more than five
	levels of parentheses"; "mine cannot initialize structs";
	"mine doesnt translate register char's correctly"; "my preprocessor
	produces garbage when identifiers of more than 16 chars are #defined";
	"my C compiler handles 10 char identifiers, but my loader retains
	only the first 6 symbols" - etc. [These are actual complaints.]
	Do you have a crappy preprocessor/compiler/loader? Too bad.
	You may choose between buying a better compiler and wasting some of
	your time each time you have to port something to your machine.)
The more programs are written in rich dialects of C the stronger the
pressure will be on compiler writers to produce compilers that perform
better than minimally.

Quite a different point is that identifiers may be mechanically generated
in some systematic and meaningful way, and in such cases it might be a pain
to distort the identifier generation scheme in such a way that no identifiers
longer than 16? 8? 7? 6? symbols are generated.