Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!philabs!cmcl2!seismo!umcp-cs!chris
From: chris@umcp-cs.UUCP (Chris Torek)
Newsgroups: net.unix-wizards
Subject: Re: Speed of seeks
Message-ID: <1535@umcp-cs.UUCP>
Date: Fri, 16-May-86 16:43:29 EDT
Article-I.D.: umcp-cs.1535
Posted: Fri May 16 16:43:29 1986
Date-Received: Sun, 18-May-86 14:53:24 EDT
References: <12593@ucla-cs.ARPA> <645@baylor.UUCP>
Reply-To: chris@maryland.UUCP (Chris Torek)
Distribution: net
Organization: University of Maryland, Dept. of Computer Sci.
Lines: 24

In article <645@baylor.UUCP> peter@baylor.UUCP (Peter da Silva) writes:
>a mistake often made by library writers is to try to make seek
>offsets simple integers. According to the library, the argument to
>an absolute seek() (lseek(fd, off, 0) or lseek(fd, off, 2)) only
>needs to be the returned value from a tell() call: it may indeed
>be a magic cookie like a sector/offset pair (and in fact "magic
>cookie" is the way it's described in the manual). It is under
>RSX/11M and on the ATARI 800.

Add `f' in front of the names (fseek, ftell) and you are correct;
Unix systems, however---or at least 4.3beta---claim that lseek
offsets are in `bytes'.  (There is no `tell' system call.)

Actually, those who write libraries such that fseek takes a byte
index either have missed that point, or are very clever:  Because
PDP-11 and Vax Unix systems have always had fseek and ftell return
byte indicies, there is no doubt quite a bit of code that depends
on that behaviour.  These programs are technically broken, but it
is hard to keep a customer happy by informing it [note non-sexist
word :-)] of this fact.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1516)
UUCP:	seismo!umcp-cs!chris
CSNet:	chris@umcp-cs		ARPA:	chris@mimsy.umd.edu