Date:	Mon, 17 Jan 2000 13:01:18 +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 AT delorie DOT com
Subject:	Re: _lleek
In-Reply-To:	<200001162057.VAA20599@father.ludd.luth.se>
Message-ID:	<Pine.SUN.3.91.1000117125848.22412A-100000@is>
MIME-Version:	1.0
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

On Sun, 16 Jan 100, Martin Str|mberg wrote:

> According to Eli Zaretskii:
> > > So it seems the file pointer wraps around at 2^32. Note particularly
> > > that I never passed a negative offset, but still the file pointer went
> > > from 2^32-2 to 2147483645 (-2 is really 2^32-2).
> > 
> > Seems like a consequence of max file size being 4GB - 2, no?  If so,
> > perhaps we should let DOS have its way here?
> 
> Please explain why seek(fd, VALUE_BIGGER_THAN_MAX, SEEK_CUR) should
> result in the file pointer at 2147483645 which is less than
> VALUE_BIGGER_THAN_MAX and not MAX_VALUE (== 2^32-2).

IMHO, both of these results are equivalently (un)reasonable, since the
call attempts to move the file pointer past its maximum possible
position.  If one of the possible outcomes avoids an extra system call,
why shouldn't we take it?

Anyway, it was just a thought.  We can always wait until someone 
complains.

> Are you saying that if someone calls _llseek with an offset of 2^35,
> you just want to pass through the bits that count to DOZE and ignore
> the other bits?

In effect, yes.  That's what we do in other cases, I think.

> Additionally this would mean _llseek(fd, -3,
> SEEK_SET) returns 2^32-3 just as _llseek(fd, 2^32-3, SEEK_SET) will
> do.

Well, that's what DOS does, right?

> A lot of functions in DJGPP tries to make DOZE functions behave
> (I thought).

Not in the primitives, like _read, _write, etc.  Primitives usually
simply call DOS, all the smart things happen at a higher level.  Unless
in this case, the primitive itself needs to be compatible to some other
system.

> > > As a matter of fact I think this is so much better that I'll suggest
> > > that lseek() calls _llseek() internally.
> > 
> > That was the original intention, at least that's what I thought it
> > was.
> 
> I don't understand this. First you say it isn't good and now you say
> it is?

I think lseek should call _llseek so that a user would never need to
distinguish between FAT16 and FAT32 volumes, not because how _llseek
does its thing.  These are two distinct issues.

- Raw text -