On Sat, 3 Jan 2026 at 18:14, Peter Eisentraut <peter@eisentraut.org> wrote:
> meson.build already contains a hint about the solution:
The comment that was there before f0f2c0c1a was better imo, because it
explained the exact problem I ran into with the new definition:
# MSVC doesn't cope well with defining restrict to __restrict, the spelling it
# understands, because it conflicts with __declspec(restrict). Therefore we
# define pg_restrict to the appropriate definition, which presumably won't
# conflict.
#
# We assume C99 support, so we don't need to make this conditional.
cdata.set('pg_restrict', '__restrict')
> Or maybe instead of writing a test, we should add something like this to
> c.h:
>
> #ifdef __cplusplus
> #ifdef __GNUC__
> #define restrict __restrict
> #else
> #define restrict
> #endif
> #endif
I don't think a test or such a define can solve this problem. The
problem is that restrict already has a meaning in MSVC C++. But it's a
different one from C restrict. It's one of the allowed arguments to
__declspec(<arg>). So if we define restrict to anything (whether
__restrict, <empty string>, or foobar) that will always cause issues
in MSVC C++, because then any usage of __declspec(restrict) in the
MSVC stdlib will be replaced with
__declspec(__restrict)/__declspec()/__declspec(foobar).
So for MSVC C++ we cannot do:
#define restrict <whatever>
Which then means that if we continue to declare functions with
restrict in for arguments in headers, then we cannot use any of those
headers in MSVC C++. Because restrict would not be valid in that
position.
I don't see any way out except a revert. To be clear, that would solve
it because we can totally do the following on MSVC C++:
#define pg_restrict __restrict
