Mail Archives: djgpp-workers/2001/10/09/20:02:29
According to Richard Dawe:
> > > I don't think the library's current behaviour is good - who knows what
> > > effect silently returning bogus sizes for files >= 2GB will have?
> >
> > As the possible values are -2^31 - 2^31-1 there no ambiguity (if
> > you're aware of that a negative value != -1 is really a big positive
> > one).
>
> 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.).
> > How does the type offset_t fit into the ways of addressing the
> > problem (if you know)?
>
> (I presume you are mean off_t rather than offset_t.)
No. I mean the type offset_t that I added for supporting FAT32 at the
same time I added llseek(). It's defined in include/sys/djtypes.h:
#define __DJ_offset_t typedef long long offset_t;
Right,
MartinS
- Raw text -