length of external names

Henry Spencer henry at utzoo.UUCP
Thu Jan 3 04:18:16 AEST 1985


> > The current draft says that the length limit (if any) and treatment
> > of case in external identifiers are "implementation-defined", which
> > means that implementors can do things as they wish but must document
> > their decisions.  Also, the length limit may not be shorter than 6.
> 
> Gads!  When are they going to figure out that 6 or 8 characters is *not*
> enough.  I spent three hours porting ogre to an Altos 586 running some
> ancient verson of Xenix and most of that was spent changing function
> names because I had only 7 signifcant characters.  I think that the standard
> should enforce a minimum of 32 characters.  We will make programs more
> portable and readable.

Oh lord, not this again...  This topic was discussed *to death* a few
months ago.  To summarize the major points that emerged:

- There are many systems which are doomed to live with old, brain-damaged
	linker formats.  Manufacturers have too big a commitment to the
	old formats to change, and their users have no say in the matter.
	It is politically vital for the acceptance of the standard that
	standard-conforming implementations be possible on such machines.
	This is regrettable but impossible to avoid.

- Trying to pick a number other than 6 is silly.  People who have a choice
	about the number can just as easily opt for no limit at all, which
	is clearly the right decision.  People who do not have a choice
	about the number generally are stuck with a rather low number,
	typically 6.

- Software which relies on long names is not fully portable, regardless of
	claims to the contrary.

- It is generally agreed that the situation is unsatisfactory and painful.

- I repeat a challenge I made at the time:  if you think a mandatory bigger
	number is appropriate despite the problems this will cause for the
	more backward systems, prove your point by convincing DEC or IBM
	to agree with you.
-- 
				Henry Spencer @ U of Toronto Zoology
				{allegra,ihnp4,linus,decvax}!utzoo!henry



More information about the Comp.lang.c mailing list