From: eplmst AT lu DOT erisoft DOT se (Martin Stromberg)
Message-Id: <199902031423.PAA19902@juno.erisoft.se>
Subject: Re: _llseeks()'s return value
To: djgpp-workers AT delorie DOT com (DJGPP-WORKERS)
Date: Wed, 3 Feb 1999 15:23:49 +0100 (MET)
In-Reply-To: <Pine.SUN.3.91.990203143053.29547o-100000@is> from "Eli Zaretskii" at Feb 3, 99 02:35:48 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com

> 
> 
> On Wed, 3 Feb 1999, Martin Stromberg wrote:
> 
> > Hmm... I seem to have a problem. _llseek() is supposed to return the
> > file pointer's (or whatever it's called) position. As there doesn't
> > seem to be any support for seek with bigger than 2^31 offsets,
> > _llseek() will have to call lseek() (potentially) several times. But
> > how is _llseek() to know what to return as lseek() only returns values
> > <= 2^31. 
> 
> Obviously, it will need to make 64-bit arithmetics itself, adding the 
> successive offsets instead of relying on `lseek'.
> 
> > Is there some internal libc structure containing the current file
> > pointer?
> 
> No.  The file pointer position is maintained by the operating system for 
> each file.
> 
> It is impossible for the library to track the file pointer reliably. 
> E.g., handles created by `dup' and `dup2' magically move together in
> sync (they all share the same position pointer), but the library cannot
> know that, especially if some of the handles belong to other processes. 

Ok. But this means _llseek() will have to reposition the pointer to
the beginning or the end of file and seek from there. And seeking from
current position won't work. Or am I missing something?
 
 
Right,
 
							MartinS