Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83 based; site homxa.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!homxa!osd7
From: osd7@homxa.UUCP (Orlando Sotomayor-Diaz)
Newsgroups: mod.std.c
Subject: mod.std.c Digest V4#18
Message-ID: <839@homxa.UUCP>
Date: Fri, 22-Mar-85 18:51:22 EST
Article-I.D.: homxa.839
Posted: Fri Mar 22 18:51:22 1985
Date-Received: Sat, 23-Mar-85 03:40:23 EST
Organization: AT&T Bell Labs, Holmdel NJ
Lines: 96
Approved: osd7@homxa.UUCP

From: Orlando Sotomayor-Diaz (The Moderator) <cbosgd!std-c>


mod.std.c Digest            Fri, 22 Mar 85       Volume 4 : Issue  18 

Today's Topics:
                          6-character names.
                fseek/ftell on files larger than 2^32
                          what ftell returns
----------------------------------------------------------------------

Date: Fri, 22 Mar 85 01:29:16 est
From: seismo!hadron!jsdy (Joseph S. D. Yao)
Subject: 6-character names.
To: std-c-std@cbosgd.ATT.UUCP

Agreeing with much of what P. Schauble said (except that I really
do worry about hashing clashes), I must make one correction.

FILES-11 on PDP-11 and VAX-11 (using some obscure thing called
VSX or something) uses 6 + 3 letters from a 40(base 10) character set.
This  i s  rad-50, as 50(8) == 40(10).  The technique was not six
six-bit chars, but rather exactly what "radix-50" implies:
((((c1*050+c2)*050+c3)*050+c4)*050+c5)*050+c6, where c[n] e [0..047].
This fit nicely into three 16-bit words: 40^3 == 64000, and
40^6 == 4096000000.  [2^16 == 65536; 2^32 == 4294967296.]

This is not to be construed as any sort of reason to perpetuate short
names.  However, if it makes it to the standard, I think we should
try to program with names significant in the shorter length, even on
enlightened machines, if there's any chance of the program's jumping
the fence.  (Of course, if we intend to burn our programs after one
use, that's a different story.	;-})

	Joe Yao		hadron!jsdy@seismo.{ARPA,UUCP}

------------------------------

Date: Fri, 22 Mar 85 09:03:44 pst
From: jonab@RDCF.SDC.S-CA.UUCP (Jonathan Biggar)
Subject: fseek/ftell on files larger than 2^32
To: std-c@cbosgd.ATT.UUCP

The solution to the problem of files sizes larger than 2^32 seems obvious
to me:

First, change fseek and ftell to use some structure called off_t.
For example:

typedef struct file_offset {
int	block;
int	char;
} off_t;

Then, to allow address calculation, just provide routines that
perform the proper calculation for the given operating system:

off_t	off_add(off, inc)
off_t	off;
long	inc;

With the proper set of standard routines, any address calculations can
be made portable to ANY operating system that allows random access files.

Jon Biggar
{allegra,burdvax,cbosgd,hplabs,ihnp4,sdccsu3}!sdcrdcf!jonab

------------------------------

Date: Fri, 22 Mar 85 01:09:31 est
From: seismo!hadron!jsdy (Joseph S. D. Yao)
Subject: what ftell returns
To: std-c@cbosgd.ATT.UUCP

I believe that at one point it was explicitly said,
"The only thing that can be said with any degree of reliability
about [what tell()/ftell() return] is that an lseek() [resp.,
fseek()] using this as an argument will return to the same place.

I tend to agree that it should not be explicitly stated to be a
long int, although it should be and will continue to be implemented
as such in many places.  However, the question was raised in net.lang.c
not long ago, and all concerned agreed that it should be an "off_t".

Since such agreement is such an unusual occurence, it can be readily
seen that this must be right.		;-)

	Joe Yao		hadron!jsdy@seismo.{ARPA,UUCP}

------------------------------

End of mod.std.c Digest - Fri, 22 Mar 85 18:30:18 EST
******************************
USENET -> posting only through cbosgd!std-c.
ARPA -> ... through cbosgd!std-c@BERKELEY.ARPA (NOT to INFO-C)
In all cases, you may also reply to the author(s) above.