On Mon, Dec 4, 2023 at 8:56 AM Jan Březina <2janbrezina@gmail.com> wrote:
> The project is not misconfigured. Windows applications use MBCS (multi byte character set) or UNICODE defines to
specifywhat Windows API they are using and there are good reasons not to mix the two.
> You should read the following documentation:
> https://learn.microsoft.com/en-us/windows/win32/intl/unicode-in-the-windows-api
> and mainly
> https://learn.microsoft.com/en-us/windows/win32/intl/conventions-for-function-prototypes
We know about that stuff at least in general terms, but we are arguing
that *we* should be in control of whether our .c files are compiled
with UNICODE defined, not someone compiling our library. That advice
is about applications. libpq is a shared library.
But let's actually check the cost of this:
> So if you are not planning to support UNICODE define, then you should be concrete in what Windows API you are using
andcall the **A (ANSI) API directly, as I suggested. It is a correct way, doesn't conflict with any defines and doesn't
conflictwith any standard API, as UNICODE define affects only the behavior of Windows API.
> I bet there won't be so much work to fix this, as Windows specific implementations are in separate *win32.c files and
henceit should not affect any other platforms and it has to work with every compiler, as it is the standard Windows
API.
What symbols is libpq.dll referencing? Maybe "dumpbin /imports
libpq.dll" can tell you? I guess that'd show us how many *A /*W
functions are reached, and would be changed to call *A directly. If
it's really just Win32 APIs that are in Windows-only code paths that'd
be one thing. I wasn't sure if it might also include standard C-ish
code that is shared with Unix.