Bulat Ziganshin wrote:
Hello Simon,
Tuesday, November 14, 2006, 4:02:09 PM, you wrote:
#ifdef mingw32_HOST_OS
if ((how & O_WRONLY) || (how & O_RDWR) || (how &
O_APPEND)) return _sopen(file,how,_SH_DENYRW,mode);
else
return _sopen(file,how,_SH_DENYWR,mode);
#else
return open(file,how,mode);
#endif
i.e. no sopen at all? in this case, other parts of library should
make proper locking for unix.
Yes, we do. See
http://darcs.haskell.org/packages/base/cbits/lockFile.c.
after some thought, i still want to complain. locking files while it's
open on Windows and using special procedure on Unix is internal trick
of Handle-based I/O library. it's bad that this trick was exposed as
non-consistent behavior of c_open call which, by its name, is
proposed for general use by other libs
i think that proper design was either to make such function internal
to GHC.Handle module, or incorporate all necessary locking logic into
the c_open/c_close and make exhaustive doc-comment to warn users
thinking that c_open should be the same as raw C open() call
in current situation when some code besides of GHC.* may rely on this
strange inconsistent behavior i think at least commenting it will be a
good idea
Well, c_open isn't a visible API: the module System.Posix.Internals is hidden in
the Haddock documentation. It isn't hidden in the package spec, but that's
because the unix package requires it. Maybe in your reorganisation of the base
package you could clean this up.
Bottom line: it's not intended for user consumption, so I don't buy your
argument. In fact I'd rather use the proper Win32 API instead of CRT functions
in the IO library.
Cheers,
Simon
_______________________________________________
Cvs-ghc mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/cvs-ghc
