Fails to compile with UNICODE defined

[computerquip-work]

inline SECURITY_STATUS AcquireCredentialsHandle(SEC_CHAR* pPrincipal,
                                                SEC_CHAR* pPackage,
                                                unsigned long fCredentialUse,
                                                void* pvLogonId,
                                                void* pAuthData,
                                                SEC_GET_KEY_FN pGetKeyFn,
                                                void* pvGetKeyArgument,
                                                PCredHandle phCredential,
                                                PTimeStamp ptsExpiry)

If the build system defines UNICODE, AcquireCredentialsHandle should expand to AcquireCredentialsHandleW where AcquireCredentialHandle uses SEC_WCHAR instead of SEC_CHAR. Thus, the following call will always fail to compile:

  return sspi_function_table()->AcquireCredentialsHandle(pPrincipal,
                                                          pPackage,
                                                          fCredentialUse,
                                                          pvLogonId,
                                                          pAuthData,
                                                          pGetKeyFn,
                                                          pvGetKeyArgument,
                                                          phCredential,
                                                          ptsExpiry);

A similar problem exists with InitializeSecurityContext as well. It might be necessary make some sort of SEC_TCHAR that defines as either SEC_WCHAR or SEC_CHAR based on if UNICODE is defined. Alternatively, instead of using the generic name that changes based on UNICODE, could just use the name wanted directly, i.e. AcquireCredentialsHandleA.

[laudrup]

I have not been able to reproduce this issue.

The way the SSPI headers are included here should ensure that the non wide-character versions of the functions are being used.

This job tests building the code with UNICODE defined, so I'm fairly confident that it works.

It might not be that best way to handle it but it would be nice with some more information before I look more into this.

Thanks.

[computerquip-work]

I'd have to take another look at it but I'd wager it's because those headers are included somewhere before wintls is included so it doesn't get the chance to define the types wintls wants.

[laudrup]

I'd have to take another look at it but I'd wager it's because those headers are included somewhere before wintls is included so it doesn't get the chance to define the types wintls wants.

That could definitely explain it and is not a use case I had thought of, but it ought to be possible to include the SSPI headers before wintls.hpp.

I think the best solution would be to always use the ANSI version of the functions and hopefully get rid of another ugly #ifdef but I have to look a bit more into it.

A pull request would be appreciated.