Date:	Sun, 23 Jan 2000 09:46:25 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	Martin Str|mberg <ams AT ludd DOT luth DOT se>
cc:	DJGPP-WORKERS <djgpp-workers AT delorie DOT com>
Subject:	Re: _llseek
In-Reply-To:	<200001201824.TAA22264@father.ludd.luth.se>
Message-ID:	<Pine.SUN.3.91.1000123094604.26609D-100000@is>
MIME-Version:	1.0
Reply-To:	djgpp-workers AT delorie DOT com
Errors-To:	dj-admin AT delorie DOT com
X-Mailing-List:	djgpp-workers AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Thu, 20 Jan 100, Martin Str|mberg wrote:

> Hmm. It seems that lseek() works as good as _llseek() except it should
> be able to return values in the range [-1, 2^32-2]. (It's
> because the DOZE call wraps around at 2^32, so -X and 2^32-X is
> equvalent in this call, so yes it'll work for lseek(fd, -3,
> SEEK_CUR).)
> 
> So either we change the return type of lseek() to long long or we have
> to add _llseek().

I didn't mean to say that _llseek shouldn't be callable on its own.
It should, or else the current offset cannot be returned for large
files.

What I meant was that lseek should call _llseek if that is needed for
proper operation on large files.  For example, if the current offset
is 2^32 - 1000, then "lseek(fd, 2^31, SEEK_CUR)" should work, even
though it returns a wrong value.  (Many programs don't care about what
lseek returns.)

But if this example works even if legacy DOS function is called, then
we don't need to call _llseek.

- Raw text -