Do we need to worry about strict provenance?

[notgull]

Right now, HWND and friends are typed as an isize; however, it seems that they are actually pointers. On certain platforms, it is considered invalid to use an *size as a pointer. However, I'm not sure how this is handled on the Windows side of things. Do we need to worry about strict provenance?

[riverar]

Hi @notgull, we had a handle/pointer provenance discussion earlier; the short version is handles aren't pointers so we're good. See also #1643

[tim-weis]

Indeed, handles are pointer-sized only, with no more than 32 significant bits. This is true for handles to USER objects (HWND, HICON, ...), GDI objects (HBRUSH, HPEN, ...), and handles to named kernel objects (mutexes, semaphores, files, ...). That's primarily to arrange for Interprocess Communication Between 32-bit and 64-bit Applications, but serves to highlight that handles aren't actually pointers.

They are typed as pointers in the C header files, presumably because fixed width integer types are a somewhat recent (C99) addition to the C programming language, with intptr_t/uintptr_t still only an optional feature.

[ChrisDenton]

One complicating factor is structures like OVERLAPPED. The hEvent should by rights be a union of a HANDLE and a c_void pointer. This is because of WriteFileEx that says:

The WriteFileEx function ignores the OVERLAPPED structure's hEvent member. An application is free to use that member for its own purposes in the context of a WriteFileEx call. WriteFileEx signals completion of its writing operation by calling, or queuing a call to, the completion routine pointed to by lpCompletionRoutine, so it does not need an event handle.

It's common to use this free member to pass a pointer to a struct.

There could be similar issues for anything that passes through a HANDLE without actually using it.