From: Martin Stromberg <eplmst AT lu DOT erisoft DOT se>
Message-Id: <200012101238.NAA13879@lws256.lu.erisoft.se>
Subject: Re: Why are we using offset_t and not off64_t?
To: djgpp-workers AT delorie DOT com
Date: Sun, 10 Dec 2000 13:38:26 +0100 (MET)
In-Reply-To: <5.0.2.1.0.20001209125228.025cbec0@pop5.banet.net> from "Peter J. Farley III" at Dec 09, 2000 12:59:52 PM
X-Mailer: ELM [version 2.5 PL3]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> 
> I'm finally getting around to putting in the FAT32 support to the new 
> fcntl, and in looking up all the types and definitions needed, I see 
> that for "long long int" offsets we are using "offset_t" instead of 
> "off64_t", such as is used in glibc-2.1.3.  Can anyone enlighten me why 

Probably because "man llseek" says this on Solaris:
"SYNOPSIS
     #include <sys/types.h>
     #include <unistd.h>

     offset_t llseek(int fildes, offset_t offset, int whence);"

> we are doing this?  Why not just lift the __USE_LARGEFILE64 and 
> __USE_FILE_OFFSET64 code from glibc's posix/sys/types.h, suitably 
> modified for DJGPP?

In my opinion it's better than using anything with 64 in it, because
what we support is approximately the range [-1, 2^32-1], which is a
lot less than what real OFFSET64 would support. 

Hmm, perhaps somebody could try creating file bigger than 2^32 on a
NTFS file system. I guess you can't through DOZE/DJGPP.


Right,

						MartinS