Incorrect usage of PHANDLE type. about win32 HOT 4 OPEN

Hi, Thanks for the report.

While I agree that the type is technically incorrect, as in PHANDLE is void** I'm not sure it really matters in this case. We've effectively declared PHANDLE as void* because there's no easy way to create a GHC.IO.Handle from this to be able to use it in Haskell functions expecting a Handle.

In case you're passing it to other Win32 functions it should be fine as well as it's an opaque value. We don't pretend to know anything about it in the Haskell world.

Whenever #51 gets done I'll make sure to correct this. Unless you want to submit a PR for it to get it done sooner?

from win32.

Any update on this? #51 seems done, via #70

from win32.

It hasn't been done yet, it's not a correctness issue so it's not particularly high on my to-do list atm I must admit. The handle is being treated as a completely opaque value in Haskell side so we assume nothing about it.

from win32.

I posted this issue two years ago, I can recall a bit why I need to represent PHANDLE as Ptr HANDLE. Consider such situation: we need create pipe and then use the in/out handle created by CreatePipe for other purpose. The signature of CreatePipe of Win32 API is

BOOL WINAPI CreatePipe(
  _Out_    PHANDLE               hReadPipe,
  _Out_    PHANDLE               hWritePipe,
  _In_opt_ LPSECURITY_ATTRIBUTES lpPipeAttributes,
  _In_     DWORD                 nSize
);

In haskell, it should be

createPipe :: PHANDLE -> PHANDLE -> LPSECURITY_ATTRIBUTES -> DWORD -> IO Bool

This is roughly how we invoke this function:

let lpattr = ...
     size = ...
(in, out) <- alloca $ \pin ->
    alloca $ \pout ->
        createPipe pin pout lpattr size
        (,) <$> (peek pin) <*> (peek pout)

If we represent PHANDLE also as Ptr (), we would need to cast pin and pout before or after invoke createPipe to get the type correct. That would lead to inconvenience and concern about type safe. The code above may not be the correct manner to use CreatePipe, but we do feel uncomfortable in certain situations.

As what is stated in the description of this issue, I think we might should obey the relation, and difference of types of Win32 API as what they are in their C/C++version, even although they are opaque.

from win32.