Date: Mon, 13 Oct 1997 14:42:15 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: Charles Sandmann <sandmann AT clio DOT rice DOT edu>
cc: djgpp-workers AT delorie DOT com
Subject: Re: Should off_t become unsigned?
In-Reply-To: <9710121843.AA16640@clio.rice.edu>
Message-ID: <Pine.SUN.3.91.971013144131.11407H-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Precedence: bulk


On Sun, 12 Oct 1997, Charles Sandmann wrote:

> They are forced to compile with -DUSE_64BIT_OFF_T (or something) which
> defines lseek to be lseek64, other routines to be consistent.  Or maybe
> this is in an alternate libc if there are a bunch of routines
> changed.

How about just providing functions like _lseek64, _ltell64 and
_stat64, for the time being?  (Does anybody know how these are called
on other systems which support large files?  I hear newer versions of 
Solaris is one of them.)

> In any case I wouldn't mess with the current working sizing/behavior.
> And I would wait for the first screams of agony about missing 2.1Gb
> file support before coding something...

It seems that the actual coding is very limited.  We need:

   - add code to `statfs', so it correctly reports disk space on FAT32
     volumes;

   - call function 6Ch instead of 3Dh to open a file (under LFN=n),
     and set the FAT32 bit in the BH register before calling DOS;

   - write the 64-bit of the three functions above, by copying the
     code from the regular functions and setting their return value to
     "long long".

Even if the last item above is not done, I suggest doing the first two
for v2.02, since they don't hurt anyone.  Comments?