GHC 6.4/mingw32: files larger than 4 GBandhFileSize/hSetFileSize/c_stat

[Simon Marlow]

On 12 April 2005 15:22, Bulat Ziganshin wrote:

> mingw32 have 32-bit off_t type; access to large files are supported
> with special functions and structures defined in msvcrrt.dll:
> 
> _CRTIMP __int64 __cdecl _lseeki64(int, __int64, int);
> _CRTIMP __int64 __cdecl _telli64(int);
> _CRTIMP int __cdecl  _fstati64(int, struct _stati64 *);
> _CRTIMP int __cdecl  _stati64(const char *, struct _stati64 *);
> struct _stati64 {
>     ....
>     __int64 st_size;
>     ....
> };
> 
> so, we need either
> 1) define COff to __int64 instead of off_t and rewrite existing
> functions to work with 64 bit filesizes
> or
> 2) define new set of low-level functions to work with 64 bit
> filesizes. define high-level functions in terms of these 64-bit
> functions on Win32
> 
> what solution will be better? in the first case COff no longer will be
> equal to off_t, what some applications can imply. in the second case
> we will add a lot of duplicating code

COff should be the same as off_t, because it is expose to the via
Foreign.C.Types.

For the I/O library, however, you could use the 64-bit interfaces
explicitly (probably confininng the changes to System.Posix.Internals).

Unix systems ususally require you to #define something to get access to
the 64-bit off_t, we rely on autoconf to tell us what this is.

Cheers,
	Simon

> is there any other (GHC-supported) environments supporting 64 bit
> filesizes, but having only 32-bit off_t?
> 
> (sorry for my bad English, i'm too far from native speaker)
> 
> 
> 
> Friday, April 08, 2005, 3:33:36 PM, you wrote:
> 
>> By all means.  If someone cares to send us a patch, we'll incorporate
>> it.
> 
>>> While GHC I/O library on mingw32 platform perfectly reads and writes
>>> files larger than 4 GB, functions hFileSize/c_fstat,
>>> hSetFileSize/c_ftruncate and c_stat are still tied to C functions
>>> returning 32 bit values and as a result truncate larger sizes to
>>> their low 32 bits. Can this behaviour be fixed in the next bug-fix
>>> version?