From:	Martin Str|mberg <ams AT ludd DOT luth DOT se>
Message-Id:	<200206161014.g5GAE6c04679@speedy.ludd.luth.se>
Subject:	Re: DJGPP and the Large File Summit (LFS)
In-Reply-To:	<3D0C5970.80BB0B9C@phekda.freeserve.co.uk> "from Richard Dawe at
	Jun 16, 2002 10:25:04 am"
To:	djgpp-workers AT delorie DOT com
Date:	Sun, 16 Jun 2002 12:14:06 +0200 (CEST)
X-Mailer:	ELM [version 2.4ME+ PL78 (25)]
MIME-Version:	1.0
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

According to Richard Dawe:
> Martin Str|mberg wrote:
> > There are no negative offsets into any file. And if you use llseek()
> > you won't (shouldn't) have a negative offset.
> 
> So how do you store +4GB - 2B in an off_t (long) _as a positive number_?

As 0xfffffffe. It's only negative because you decide to see it as
negative. But you should store it in offset_t, which have bigger a
range, not off_t, That's why we have llseek().

> I think we're arguing at cross-purposes. Let's try this. I believe we can
> currently do this:
> 
>     lseek(fd, 0, SEEK_SET);
>     lseek(fd, 2GB - 1B, SEEK_CUR);
>     lseek(fd, 2GB - 1B, SEEK_CUR);
> 
> So now the file position is at 4GB - 2B. But lseek can't return the offset as
> a positive number in the final call. 2GB - 1B is the maximum offset we can

Yes. It'll look like -2, but if offset is < -1 you should add 4GiB.

> represent in the positive portion of a long. 'ls' (IIRC which program) from
> Fileutils has already been bitten by this bug.

Yes. And I think the solution is llseek(). At least that was my idea
when I wrote it.

> * It won't let you seek beyond the maximum offset [that you can represent in
> the positive portion of off_t]. This is where the file manipulation files
> return -1 and errno == EOVERFLOW.

Then change lseek() to guard for this. (Use llseek() and some math to
check for "overflow".)

Or perhaps this is what you intend to do?


Right,

						MartinS

- Raw text -