Re: BUG #18219: libpq does not take into consideration UNICODE define - Mailing list pgsql-bugs

From Jan Březina
Subject Re: BUG #18219: libpq does not take into consideration UNICODE define
Date
Msg-id CABODNCyDZLbA1pK0YyxkjrbpN2mEu=hDBkeGxhJbHR-LFR3mkw@mail.gmail.com
Whole thread Raw
In response to Re: BUG #18219: libpq does not take into consideration UNICODE define  (Thomas Munro <thomas.munro@gmail.com>)
List pgsql-bugs
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);


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.munro@gmail.com> napsal:
On Fri, Dec 1, 2023 at 10:10 AM Jan Březina <2janbrezina@gmail.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.

pgsql-bugs by date:

Previous
From: Thomas Munro
Date:
Subject: Re: BUG #18219: libpq does not take into consideration UNICODE define
Next
From: Thomas Munro
Date:
Subject: Re: BUG #18219: libpq does not take into consideration UNICODE define