__hscore_open from HsBase.h

[Simon Marlow]

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