Re: pg_attribute_noreturn(), MSVC, C11

From: Andres Freund <andres(at)anarazel(dot)de>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org, Peter Eisentraut <peter(at)eisentraut(dot)org>
Cc: pgsql-hackers(at)postgresql(dot)org, Dagfinn Ilmari Mannsåker <ilmari(at)ilmari(dot)org>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Subject: Re: pg_attribute_noreturn(), MSVC, C11
Date: 2025-03-10 14:38:59
Message-ID: 8AB9E72E-C652-4316-B27E-41100A19EA77@anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On March 10, 2025 10:37:43 AM EDT, Peter Eisentraut <peter(at)eisentraut(dot)org> wrote:
>On 10.03.25 14:58, Andres Freund wrote:
>>> diff --git a/src/backend/utils/mmgr/slab.c b/src/backend/utils/mmgr/slab.c
>>> index ec8eddad863..d32c0d318fb 100644
>>> --- a/src/backend/utils/mmgr/slab.c
>>> +++ b/src/backend/utils/mmgr/slab.c
>>> @@ -601,8 +601,8 @@ SlabAllocFromNewBlock(MemoryContext context, Size size, int flags)
>>> * want to avoid that.
>>> */
>>> pg_noinline
>>> +pg_noreturn
>>> static void
>>> -pg_attribute_noreturn()
>>> SlabAllocInvalidSize(MemoryContext context, Size size)
>>> {
>>> SlabContext *slab = (SlabContext *) context;
>> Hm, is it good to put the pg_noreturn after the pg_noinline?
>
>I probably just did them alphabetically. I don't think there would be a problem, since pg_noinline is an attribute, and they can generally be put everywhere. At least until we learn otherwise.

Just seems easier to document that no return etc should go first. But it's not important.

Andres
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Shubham Khanna 2025-03-10 14:42:35 Re: Adding a '--clean-publisher-objects' option to 'pg_createsubscriber' utility.
Previous Message Peter Eisentraut 2025-03-10 14:37:43 Re: pg_attribute_noreturn(), MSVC, C11