delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/2000/01/16/15:57:44

From: Martin Str|mberg <ams AT ludd DOT luth DOT se>
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
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

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

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019