Re: pg_attribute_noreturn(), MSVC, C11 - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: pg_attribute_noreturn(), MSVC, C11
Date
Msg-id 47f33031-0704-45f9-a0eb-650c0d7f4a3a@eisentraut.org
Whole thread Raw
In response to pg_attribute_noreturn(), MSVC, C11  (Andres Freund <andres@anarazel.de>)
Responses Re: pg_attribute_noreturn(), MSVC, C11
List pgsql-hackers
On 13.02.25 16:34, Peter Eisentraut wrote:
> On 22.01.25 19:16, Peter Eisentraut wrote:
>> On 06.01.25 15:52, Peter Eisentraut wrote:
>>> On 03.01.25 21:51, Dagfinn Ilmari Mannsåker wrote:
>>>> Peter Eisentraut <peter@eisentraut.org> writes:
>>>>
>>>>> I suggest we define pg_noreturn as
>>>>>
>>>>> 1. If C11 is supported, then _Noreturn, else
>>>>> 2. If GCC-compatible, then __attribute__((noreturn)), else
>>>>
>>>> Would it be worth also checking __has_attribute(noreturn)?  Or do all
>>>> compilers that have __attribute__((noreturn)) claim to be GCC?
>>>
>>> I don't think that would expand the set of supported compilers in a 
>>> significant way.  We can always add it if we find one, of course.
>>
>> In fact, as another thought, we could even drop #2.  Among the GCC- 
>> compatible compilers, both GCC and Clang have supported #1 for ages, 
>> and the only other candidate I could find on the build farm is the 
>> Solaris compiler, which also supports C11 by default, per its 
>> documentation.
>>
>>>>> 3. If MSVC, then __declspec((noreturn))
> 
> Here is an updated patch set that contains the above small change and 
> fixes some conflicts that have arisen in the meantime.

Another rebased patch set, no further changes.

Attachment

pgsql-hackers by date:

Previous
From: Nazir Bilal Yavuz
Date:
Subject: Re: per backend WAL statistics
Next
From: Kirill Reshke
Date:
Subject: Re: Extensible storage manager API - SMGR hook Redux