Date: Wed, 3 Feb 1999 14:35:48 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Martin Stromberg <eplmst AT lu DOT erisoft DOT se>
cc: DJGPP-WORKERS <djgpp-workers AT delorie DOT com>
Subject: Re: _llseeks()'s return value
In-Reply-To: <199902031053.LAA19755@juno.erisoft.se>
Message-ID: <Pine.SUN.3.91.990203143053.29547o-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
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.