Mail Archives: djgpp-workers/2001/10/11/03:21:12
Richard said:
> Martin Str|mberg wrote:
> >
> > According to Richard Dawe:
> > > Sure, there's no ambiguity for stat alone. But if you report the file
> > > size as > 2GB in stat, then you may not be able to manipulate some
> > > portions of the file. E.g. you may want to use relative seeks to get
> > > to the top 2GB of a file, but you can't, because off_t is a signed
> > > value and cannot be used to represent a seek to > +2GB of the current
> > > position. How would you interpret the seek to > +2GB, when you can't
> > > represent > +2GB, because negative values are used for backwards
> > > seeking?
> >
> > Easily. You just send in 2GiB + 10 (e. g.) which is a very
> > magnitudeally big number (but negative) and it works! Because every
> > seek operation works mod 2^32 and/or x86 uses two's complement for
> > signed numbers. This is a conclusion I've made after trying to
> > understand what was happening when I called the DOZE (INT 21 driven)
> > seek function with SEEK_SET and offset -2^30 (e. g.).
>
> OK, but that only works because of the arithmetic. I'm talking about an
> inconsistency in the handling of off_t. Say you seek to near to 2GB using
> lseek's SEEK_SET. You then seek to 1GB using lseek and SEEK_CUR. Now you
> want to seek to somewhere in the first 1GB of the file. How do you do it?
> You need to use lseek and SEEK_CUR with an offset that is negative and >
> 2GB in magnitude.
>
> off_t does not allow us to handle the full extent of files > 2GB in size,
> because off_t is too small right now. Hence this thread.
No. You don't get it. It the same exercise again. You pass in the
negative number and it doesn't matter. It will seek to the right
place.
Right,
MartinS
- Raw text -