SECURITY_ATTRIBUTES for windows is still not implemented

[MaikKlein]

typedef struct _SECURITY_ATTRIBUTES {
  DWORD  nLength;
  LPVOID lpSecurityDescriptor;
  BOOL   bInheritHandle;
} SECURITY_ATTRIBUTES, *PSECURITY_ATTRIBUTES, *LPSECURITY_ATTRIBUTES;

See https://github.com/MaikKlein/ash/blob/master/generator/src/lib.rs#L357-L360

Should we use a library for this? Or should we just implement it manually?

[Ralith]

winapi defines this. Reusing the de-facto standard crate seems nice, unless anyone can think of any serious drawbacks.

[aloucks]

Adding the winapi dependency for a single struct definition seems like overkill. I would probably just implement it manually.

[MarijnS95]

With windows-rs we could generate just the bindings for this type. Binding generation and compiling is crazy fast, but the Windows crate and generator itself are pretty slow to compile.

Then there's the obvious problem of crate incompatibility: crate users will have their own bindings which are type-incompatible despite carrying the same name and layout. Is there any reason this type is needed, do we have to access the fields from within Ash?

Otherwise we should probably keep all such pointers opaque types like c_void and leave it up to the caller to perform the pointer cast from their own type.

[Ralith]

I'm strongly in favor of an opaque pointer if it's sufficient. That seems to be the current case?

[MarijnS95]

Otherwise we should probably keep all such pointers opaque types like c_void and leave it up to the caller to perform the pointer cast from their own type.

As noted in #950 this is not actually a pointer to easily cast, but a mutable borrow - and this doesn't allow NULL values either even though the documentation suggests it should be valid.

Perhaps we should add it to the list of "opaque types" there to solve both issues?