Path: utzoo!mnetor!uunet!oddjob!mimsy!eneevax!umd5!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.lang.c
Subject: Re: a couple of random questions
Message-ID: <7706@brl-smoke.ARPA>
Date: 16 Apr 88 04:40:41 GMT
References: <530@vsi.UUCP> <10426@steinmetz.ge.com> <541@vsi.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Distribution: comp
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 17

In article <541@vsi.UUCP> friedl@vsi.UUCP (Stephen J. Friedl) writes:
>I believe that dpANS does not address lseek(2) because it is an
>operating system function; they specify fseek(3) instead, where
>the offset is defined to be in characters.  Presumably the stdio
>library is required to "just figure it out" on a record-based
>system.  I've seen it written somewhere that the only portable
>way to get an lseek(2) offset is as a result from a previous lseek(2).

lseek() is not in the dpANS for C because it refers to a file descriptor,
and no file-descriptor oriented functions are permitted in the dpANS.
POSIX (actually IEEE 1003.1) on the other hand intends to standardize
such functions.

lseek() works in bytes, using the UNIX file model (sequence of bytes).
fseek() to an absolute position only works PORTABLY if the cookie you
give it is one obtained from ftell().  rewind() will always do what
one would think.