Date: Mon, 17 Jan 2000 13:01:18 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: Martin Str|mberg cc: djgpp-workers AT delorie DOT com Subject: Re: _lleek In-Reply-To: <200001162057.VAA20599@father.ludd.luth.se> Message-ID: 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 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.