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?