The friendly overload for `AdjustTokenPrivileges()` is inconsistent.

[mjr4077au]

Actual behavior

The friendly overload for AdjustTokenPrivileges() requires a pointer to TOKEN_PRIVILEGES for NewState, but uses Span<byte> for PreviousState.

internal static unsafe winmdroot.Foundation.BOOL AdjustTokenPrivileges(SafeHandle TokenHandle, winmdroot.Foundation.BOOL DisableAllPrivileges, winmdroot.Security.TOKEN_PRIVILEGES* NewState, Span<byte> PreviousState, out uint ReturnLength)
{
}

Expected behavior

Consistent parameters for each type. Ideally in winmdroot.Security.TOKEN_PRIVILEGES NewState/out winmdroot.Security.TOKEN_PRIVILEGES* PreviousState.

Repro steps

N/A

1. NativeMethods.txt content:

AdjustTokenPrivileges

2. NativeMethods.json content (if present):
   N/A

3. Any of your own code that should be shared?
   N/A

Context

• CsWin32 version: 0.3.253
• Win32Metadata version (if explicitly set by project): N/A
• Target Framework: net472
• LangVersion (if explicitly set by project): N/A

[jevansaks]

The metadata does not have any size annotation on the NewState parameter, that's why it remains pointer. PreviousState does have a length annotation, hence the inconsistency.

Reading the documentation, it doesn't even say how much of the NewState pointer the function is going to read from, so I'm not even sure what the fix could be.

[mjr4077au]

That's fair enough. Can/should it take TOKEN_PRIVILEGES as an in struct, then the friendly wrapper fixes it in place and passes the fixed address through?

[jevansaks]

TOKEN_PRIVILEGES has a [FlexibleArray] field so "in TOKEN_PRIVILEGES" would be misleading, callers need to think about how to size the buffer to handle it.

I can look into why the param isn't getting changed to Span, though. As an in parameter pointing at a flexible array thing, Span is friendlier than the raw pointer, and that was the intent with one of my earlier changes for these types of params. Maybe because it's only "in" it isn't getting covered by the logic.

[jevansaks]

I made the change to do this but I'm not feeling confident it's 100% better. There's some cases (e.g. SAFEARRAY and that family of functions) where the delta makes things a bit odd. One could argue that SAFEARRAY probably deserves to be wrapped into a synthetic handle type. But especially the fact that we're suggesting the parameter is a Span but then not doing anything with the length is a bit disingenuous also.

I'll put up the PR as a draft but I'm going to sit on it for a while.

[mjr4077au]

There's no rush on my end, there's always workarounds for these things. You're doing god's work here, so take all the time you need 😁