From: eplmst AT lu DOT erisoft DOT se (Martin Stromberg)
Message-Id: <199902040938.KAA20522@juno.erisoft.se>
Subject: Re: _llseeks()'s return value
To: eliz AT is DOT elta DOT co DOT il (Eli Zaretskii)
Date: Thu, 4 Feb 1999 10:38:38 +0100 (MET)
Cc: djgpp-workers AT delorie DOT com (DJGPP-WORKERS)
In-Reply-To: <Pine.SUN.3.91.990203184129.21364B-100000@is> from "Eli Zaretskii" at Feb 3, 99 06:50:37 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

Eli said:
> On Wed, 3 Feb 1999, I wrote:
> 
> > > Somebody doesn't happen to know some interrupt for seeking that
> > > returns valid data on file positions bigger than 2^31?
> > 
> > I will try to search my references.
> 
> I looked, but didn't find anything.
> 
> You could work around the problem by going all the way back to the 
> beginning of the file from the original position, and then computing the 
> final position on your own, though.  The simple-minded way would be to go 
> back one byte at a time until you hit the beginning; a much faster way is 
> to use whatever is returned by lseek as the step size, until you get past 
> the beginning, then compute the size by adding the last (negative) result 
> with the positive steps you did before that.
> 
> If the above works and isn't too slow, maybe that's the way to go?

It won't work, because I don't know when I've reached the beginning:

lseek(x, -1, SEEK_CUR) returns -1 if the file pointer is at zero or at
2^31.


However it seems the solution has been in front of our eyes all the
time. The interrupt lseek() uses (don't remember which one) seems to
fill in some data in edx&0xffff0000. Now all I have to do is find the
right bits to mask in and out, and perhaps it'll work!


Right,

							MartinS