Re: remove pg_restrict workaround

From: Peter Eisentraut <peter(at)eisentraut(dot)org>
To: Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: remove pg_restrict workaround
Date: 2026-01-03 17:14:45
Message-ID: 98cc3f46-b2ae-4120-b902-f41158ffd44e@eisentraut.org
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 03.01.26 00:23, Jelte Fennema-Nio wrote:
> On Wed, 29 Oct 2025 at 08:04, Peter Eisentraut <peter(at)eisentraut(dot)org> wrote:
>> Committed with a backward compatibility define.
>
> I'm working on adding a C++ extension module to my copyObject
> patchset[1]. But turns out that this change has completely broken
> compiling C++ extensions on MSVC. This is happening due to
> __declspec(restrict) being replaced by __declspec(__restrict), which
> the original comments also mentioned as the reason for having our own
> flavor. This replacement then makes the core of a corecrt_malloc.h
> MSVC header invalid[2].

meson.build already contains a hint about the solution:

# Even though restrict is in C99 and should be supported by all
# supported compilers, this indirection is useful because __restrict
# also works in C++ in all supported compilers. (If not, then we
# might have to write a real test.) (restrict is not part of the C++
# standard.)
cdata.set('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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2026-01-03 17:23:01 Re: some Page/PageData const stuff
Previous Message David E. Wheeler 2026-01-03 17:14:00 Re: access numeric data in module