From: Martin Str|mberg <ams AT ludd DOT luth DOT se>
Message-Id: <200001122133.WAA20314@father.ludd.luth.se>
Subject: _lleek
To: djgpp-workers AT delorie DOT com (DJGPP-WORKERS)
Date: Wed, 12 Jan 100 22:33:32 +0100 (MET)
X-Mailer: ELM [version 2.4ME+ PL15 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com

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. But the possibility to get correct return values outweights that
performance penalty, I think. 

Example:

ret = _llseek(fd, 0, SEEK_SET); /* File pointer is at 0, ret is 0. */
ret = _llseek(fd, 10, SEEK_SET); /* File pointer is at 10, ret is 10. */
ret = _llseek(fd, -12, SEEK_CUR); /* File pointer is at 0, ret is 0. */
ret = _llseek(fd, MAX_SIZE_IN_FAT32, SEEK_SET); /* File pointer is at
MAX_SIZE_IN_FAT32, ret is MAX_SIZE_IN_FAT32. */
ret = _llseek(fd, 3, SEEK_CUR); /* File pointer is at
MAX_SIZE_IN_FAT32, ret is MAX_SIZE_IN_FAT32. */

Would that be good or reasonable?


Shostakovich, Symphony 6,

							MartinS