Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!cmcl2!rutgers!ucla-cs!zen!ucbvax!decvax!decwrl!sun!gorodish!guy
From: guy%gorodish@Sun.COM (Guy Harris)
Newsgroups: comp.unix.questions
Subject: Re: (Probably dumb) SysVR3 questions
Message-ID: <25531@sun.uucp>
Date: Thu, 13-Aug-87 05:23:44 EDT
Article-I.D.: sun.25531
Posted: Thu Aug 13 05:23:44 1987
Date-Received: Sat, 15-Aug-87 09:08:36 EDT
References: <2541@tekgvs.TEK.COM> <1237@hropus.UUCP> <25420@sun.uucp> <6279@brl-smoke.ARPA>
Sender: news@sun.uucp
Distribution: na
Lines: 24

> >COFF, unfortunately, thinks file names are limited to 14 characters (I
> >presume this is the source of SGS's problem), but that's just a botch.
> >You could stick longer file names in the string table, and just have first
> >4 bytes of the filename auxiliary entry be zero and the next 4 be a string
> >table index.
> 
> All "ar" utilities I know of, including 4.2BSD's, restrict member names
> to something like 14 or 16 characters.

I'm quite aware of that.  However:

> Thus the problem is not restricted to COFF filename entries.

*Which* problem?  I haven't seen any serious problem caused by the 14-character
limitation in "ar"; nuisances, yes, but no serious problems.  However, there
*is* a problem with using COFF on systems that do not limit file names to 14
characters, namely that the C_FILE entry can't represent them.  This problem
most definitely *is* restricted to COFF filename entries; the 4.2BSD scheme,
wherein auxiliary information is encoded in a string whose length does not have
a set limit, does not have this problem.  (This scheme avoids lots of other
problems with COFF's debugger symbols as well.)
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy@sun.com