From: Martin Stromberg <Martin DOT Stromberg AT epl DOT ericsson DOT se>
Message-Id: <200110120744.JAA24662@lws256.lu.erisoft.se>
Subject: Re: Resend: DJGPP and files > 2GB
To: djgpp-workers AT delorie DOT com
Date: Fri, 12 Oct 2001 09:44:23 +0200 (MET DST)
In-Reply-To: <3BC5F4AF.A9459A35@phekda.freeserve.co.uk> from "Richard Dawe" at Oct 11, 2001 08:36:15 PM
X-Mailer: ELM [version 2.5 PL3]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

Richard said:
> Martin Stromberg wrote:
> > Richard said:
> [snip]
> > > off_t does not allow us to handle the full extent of files > 2GB in
> > > size, because off_t is too small right now. Hence this thread.
> > 
> > No. You don't get it. It the same exercise again. You pass in the
> > negative number and it doesn't matter. It will seek to the right
> > place.
> 
> I'm not convinced by your argument. Consider relative seeks:
> 
> lseek(fd, SEEK_SET, 2GB - 10);
> lseek(fd, SEEK_CUR, 1GB);
> 
> Now I want to seek backwards 2.5GB. How would I do that? How does lseek

lseek(fd, SEEK_CUR, -2.5GB) (or lseek(fd, SEEK_CUR, -2.5GB + 2^32),
it's the same thing).

> know which direction I want to go for relative seeks with |offset| > 2GB?

It doesn't and doesn't need to as everything is done mod 2^32. _Or_
perhaps it does and acts differently depending on current position and
seek offset.

> Incidentally, why does lseek check whether the file descriptor is a pipe
> or not, after it's done the INT21h call? Shouldn't it do it before the
> interrupt?

Don't know.


Right,

						MartinS