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
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. 

- Raw text -