Sender: rich AT phekda DOT freeserve DOT co DOT uk
Message-ID: <3BC4A730.BCCB32D0@phekda.freeserve.co.uk>
Date: Wed, 10 Oct 2001 20:53:20 +0100
From: Richard Dawe <rich AT phekda DOT freeserve DOT co DOT uk>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19 i586)
X-Accept-Language: de,fr
MIME-Version: 1.0
To: djgpp-workers AT delorie DOT com
Subject: Re: Resend: DJGPP and files > 2GB
References: <200110100001 DOT CAA17010 AT father DOT ludd DOT luth DOT se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com

Hello.

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.

> > > 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;

This looks equivalent to off64_t (a 64 bit wide version of off_t) as
described by the Large File Summit transitional API. llseek and llockf
look equivalent to the lseek64 and lockf64 functions described in the LFS
transitional API.

It might be a good idea to implement the transitional API (*64 versions of
the file handling functions), renaming the ll* functions as part of the
work.

FYI glibc supports both the transitional API and the large file versions
of open, etc.

Bye, Rich =]

-- 
Richard Dawe
http://www.phekda.freeserve.co.uk/richdawe/