Date: Thu, 13 Jan 2000 09:40:06 +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: _lleek
In-Reply-To: <200001122133.WAA20314@father.ludd.luth.se>
Message-ID: <Pine.SUN.3.91.1000113093949.9693S-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 Wed, 12 Jan 100, Martin Str|mberg wrote:

> I've been thinking about the problem that the _llseek call can't
> figure out if the position is negative or positive by calling
> _llseek(fd, 0, SEEK_CUR).
> 
> I think I've found a solution: if _llseek checks the position first
> before moving the file pointer, and limits the movement of the pointer
> to be withing [ 0, MAX_SIZE_IN_FAT32].
> 
> This requires an extra call to the INT21 function for the SEEK_CUR
> case.

I don't see anything wrong with this, but could you please reiterate
the exact nature of the problem?  It's a long time since we discussed
this.

Didn't you tell at one point that the maximum file size on FAT32 is
less than 2^32, and that this could help us solve the problems?