Re: BUG #18219: libpq does not take into consideration UNICODE define

On Fri, Dec 1, 2023 at 10:50 AM Jan Březina <2janbrezina(at)gmail(dot)com> wrote:
> It's pretty common to handle UNICODE define on Windows AFAIK. I suggest two ways of handling the issue.
> 1. pass the appropriate type if UNICODE is defined:
> #ifdef UNICODE
> LoadLibraryEx(L"ntdll.dll", nullptr, 0);
> #else
> LoadLibraryEx("ntdll.dll", nullptr, 0);
> #endif

But this would apply to many, many places where we call system
functions, no? I guess you've just picked on this one case because it
was the first thing to break. In some cases the string to be provided
is not a constant, so would require passing through char/wchar_t
conversion routines. Seems like a non-starter.

> 2. Use **A functions no matter what (everywhere)
> LoadLibraryExA("ntdll.dll", nullptr, 0);
>
> https://learn.microsoft.com/en-us/windows/win32/api/libloaderapi/nf-libloaderapi-loadlibraryexa
>
> See, LoadLibraryEx is affected by the UNICODE define within the Windows header files. It's LoadLibraryExW if it's defined, or LoadLibraryExA if it's not:
>
> #ifdef UNICODE
> #define LoadLibraryEx LoadLibraryExW
> #else
> #define LoadLibraryEx LoadLibraryExA
> #endif

Right, but since some of the functions that are affected in this way
are also standardised functions that we call on POSIX systems, I think
we'd finish up scattering more #ifdef #else stuff all through the code
to explicitly select the 'ANSI' (sic) Windows variant or the
standardised-function-with-no-suffix variant. Also seems like a
non-starter.