From: Martin Str|mberg Message-Id: <200001162057.VAA20599@father.ludd.luth.se> Subject: Re: _lleek To: djgpp-workers AT delorie DOT com Date: Sun, 16 Jan 100 21:57:26 +0100 (MET) Cc: eliz AT is DOT elta DOT co DOT il (Eli Zaretskii) In-Reply-To: <200001161946.OAA18699@indy.delorie.com> from Eli Zaretskii at "Jan 16, 0 02:46:50 pm" 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 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 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). > > > > if( whence == SEEK_SET ) > > > > { > > > > if( offset < 0 ) > > > > { > > > > offset = 0; > > > > } > > > > else if( MAX_FILE_POINTER_POSITION < offset ) > > > > { > > > > offset = MAX_FILE_POINTER_POSITION; > > > > } > > > > } > > > > > > What happens if you pass the offset unaltered to DOS? Why should we > > > silently change the arguments, unless they somehow crash the system or > > > wipe the disk? > > > > The total number of bits there are place for in the call (INT21, > > AH=0x42) is 32. So passing bigger values than 2^32 will be the same as > > passing the value modulus 2^32. > > But you don't take the modulus, you limit the arguments. I wonder if > we should do that. The modulus is taken (it's a consequence of the DOZE call). The only difference is I don't allow negative values (which has little use, in particular as they will be seen as big positive ones) and likewise too big values that will be modulus 2^32. Plus the single bad value 2^32-1 will be decreased to the maximum allowed, 2^32-2. You can see the above code as my way of masking away the bits that won't fit in the registers passed to DOZE. If you'll be happier I could change the constant MAX_FILE_POINTER_POSITION to 2^32-1, but then I don't know what the DOZE call will do. Perhaps it'll take a step backwards as the offset can't be bigger than 2^32-2, hence it must be -1?! 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? Additionally this would mean _llseek(fd, -3, SEEK_SET) returns 2^32-3 just as _llseek(fd, 2^32-3, SEEK_SET) will do. > > The biggest size of a file in FAT is > > 2^32-1 <=> biggest offset is 2^32-2. Hence bigger values than 2^32-2 > > doesn't make sense. > > IMHO it is not a business of a library function to decide what does > and what doesn't make sense. I say let's pass the arguments unaltered > to DOS. We can document all the quirks, if you think it's important. Well that view is ok if the OS behaves sensibly, which isn't the case here. A lot of functions in DJGPP tries to make DOZE functions behave (I thought). > > 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? Right, MartinS