Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Incorrect usage of PHANDLE type. #61

Open
sighingnow opened this issue Nov 15, 2016 · 4 comments
Open

Incorrect usage of PHANDLE type. #61

sighingnow opened this issue Nov 15, 2016 · 4 comments

Comments

@sighingnow
Copy link

In convension of win32 API, PHANDLE means "A pointer to a HANDLE"[1]. However in System/Win32/DebugApi.hsc PHANDLE was wrongly used to represent "process handle". Maybe some more precise tokens such as ProcHANDLE and ThreadHandle can be used to distinguish process handle, thread handle and ordinay handles.

I think the type synonym PHANDLE should be defined as type PHANDLE = Ptr HANDLE in System/Win32/Types.hs and should be available after we import the module System.Win32.Types and then it can be used directly with some win32 functions like CreatePipe.

1: https://msdn.microsoft.com/en-us/library/windows/desktop/aa383751(v=vs.85).aspx

@Mistuke
Copy link
Contributor

Mistuke commented Nov 15, 2016

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?

@no-identd
Copy link

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

@Mistuke
Copy link
Contributor

Mistuke commented Dec 7, 2018

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.

@sighingnow
Copy link
Author

sighingnow commented Dec 8, 2018

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.

bgamari pushed a commit to bgamari/win32 that referenced this issue Sep 10, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants