This sounds like a good idea to me. As far as possible, we should keep the platform-dependence restricted to the implementation of one module (System.Posix.Internals will do, even though this isn't really POSIX any more). So System.Posix.Internals exports the CFilePath/CFileOffset types, and the foreign functions that operate on them.
Alternatively (and perhaps this is better), we could hide the difference even further, and provide functions like rmDir :: FilePath -> IO CInt in System.Posix.Internals. Similarly for functions that operate on COff, they would take/return Integer (eg. we already have System.Posix.fdFileSize). As regards whether to use feature tests or just #ifdef mingw32_HOST_OS, in general feature tests are the right thing, but sometimes it doesn't buy you very much when there is (and always will be) only one platform that has some particular quirk. Writing a bunch of autoconf code that would, if we're lucky, handle properly the case when some future version of Windows removes the quirk, is not a good use of developer time. Furthermore, Windows hardly ever changes APIs, they just add new ones. So I don't see occasional use of #ifdef mingw32_HOST_OS as a big deal. It's more important to organise the codebase and make sure all the #ifdefs are behind suitable abstractions. Cheers, Simon On 21 November 2005 12:01, Bulat Ziganshin wrote: > Simon, what you will say about the following plan? > > ghc/win32 currently don't support operations with files with Unicode > filenames, nor it can tell/seek in files for positions larger than 4 > GB. it is because Unix-compatible functions open/fstat/tell/... that > is supported in Mingw32 works only with "char[]" for filenames and > off_t (which is 32 bit) for file sizes/positions > > half year ago i discussed with Simon Marlow how support for unicode > names and large files can be added to GHC. now i implemented my own > library for such files, and got an idea how this can incorporated to > GHC with minimal efforts: > > GHC currently uses CString type to represent C-land filenames and COff > type to represent C-land fileseizes/positions. We need to > systematically change these usages to CFilePath and CFileOffset, > respectively, defined as follows: > > #ifdef mingw32_HOST_OS > type CFilePath = LPCTSTR > type CFileOffset = Int64 > withCFilePath = withTString > peekCFilePath = peekTString > #else > type CFilePath = CString > type CFileOffset = COff > withCFilePath = withCString > peekCFilePath = peekCString > #endif > > and of course change using of withCString/peekCString, where it is > applied to filenames, to withCFilePath/peekCFilePath (this will touch > modules System.Posix.Internals, System.Directory, GHC.Handle) > > the last change needed is to conditionally define all "c_*" functions > in System.Posix.Internals, whose types contain references to filenames > or offsets: > > #ifdef mingw32_HOST_OS > foreign import ccall unsafe "HsBase.h _wrmdir" > c_rmdir :: CFilePath -> IO CInt > .... > #else > foreign import ccall unsafe "HsBase.h rmdir" > c_rmdir :: CFilePath -> IO CInt > .... > #endif > > (note that actual C function used is _wrmdir for Windows and rmdir for > Unix). of course, all such functions defined in HsBase.h, also need to > be defined conditionally, like: > > #ifdef mingw32_HOST_OS > INLINE time_t __hscore_st_mtime ( struct _stati64* st ) { return > st->st_mtime; } #else > INLINE time_t __hscore_st_mtime ( struct stat* st ) { return > st->st_mtime; } #endif > > That's all! of course, this will broke compatibility with current > programs which directly uses these c_* functions (c_open, c_lseek, > c_stat and > so on). this may be issue for some libs. are someone really use these > functions??? of course, we can go in another, fully > backward-compatible way, by adding some "f_*" functions and changing > high-level modules to work with these functions _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users