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

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

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

Dne čt 30. 11. 2023 22:21 uživatel Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
napsal:

> On Fri, Dec 1, 2023 at 10:10 AM Jan Březina <2janbrezina(at)gmail(dot)com> wrote:
> > I defined UNICODE for the whole project and it's propagated also to the
> dependencies. Vcpkg is just the package manager. You can see it's port in
> the public repository:
> https://github.com/Microsoft/vcpkg/blob/master/ports/libpq/portfile.cmake
>
> I see. Well, generally speaking PostgreSQL just isn't going to work
> if some external thing #defines a bunch of stuff that changes the
> meaning of system headers. For example on Unix systems there are
> various headers that will tell some systems to use various ancient
> standards instead of the modern POSIX semantics, and if you #define
> those, surprise!, PostgreSQL will not work. But I'm not a Windows
> person so I have no real opinion on whether that particular thing
> would be reasonably expected to work and is something that people
> typically go around doing. What would you suggest? Should we
> explicitly #undef it, is that what people do? My guess is that there
> is 0% chance that we'll ever modify our OWN behaviour due to UNICODE
> (that is, our C functions are not going to have a wchar_t version that
> UNICODE silently selects that you can call, you'll always have to talk
> to our code with char strings AFAICS), but as for how our own .c files
> internally talk to the system headers, that's kinda private to our
> source tree, so I guess it would at least be theoretically possible
> for us to nail that down with a well placed #undef. I just don't know
> how sensible or typical that would be.
>