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
Content-Type: TEXT/PLAIN; charset=US-ASCII
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
Precedence: bulk


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.