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

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

- Raw text -