Mail Archives: djgpp-workers/2000/01/16/15:03:56
> According to Eli Zaretskii:
> > If whence == SEEK_CUR and offset is positive, you could avoid the double
> > call, no?
[snip]
> 1: ret = 2147483647.
> 2: ret = -2.
> 3: ret = 2147483645.
> bash$
>
> 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?
> > > 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 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.
> 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.
Thanks again for the explanations.
- Raw text -