| From: | Roman Khapov <rkhapov(at)yandex-team(dot)ru> |
|---|---|
| To: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | *_LAST in enums to define NUM* macross |
| Date: | 2025-11-18 13:51:18 |
| Message-ID: | AE2C8BD8-06DB-4478-8FA1-CA89789ACACB@yandex-team.ru |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi all!
Recently we rebased one of our internal patches, which defines new ProcSignalReason value onto pgsql18 and encountered a bug
related to NUM_PROCSIGNALS. The patch was written for and older pgsql version, where NUM_PROCSIGNALS was defined
as value of the enum, but now it is equal to (PROCSIG_RECOVERY_CONFLICT_LAST + 1).
As the result, the rebase (which was successful) led to incorrect value of NUM_PROCSIGNALS and runtime error
with usage of pss_signalFlags.
I thought about how to prevent such errors in the future, and realized that the recipe for this is already in
ProcSignalReason - you need to declare LAST elements equal to one of the enum values and use them when declaring NUM macros.
Based on commit 10b7218, I extended this pattern by adding *_LAST elements and updating NUM-like macros in other
modified enums within this patch (see attachment).
Please note, that this will not lead to extra compiler warnings about writing switch statements on enum values,
because LAST value in enums is always equal to some other value of the enum.
Any thoughts or suggestions on this approach?
—
Best regards,
Roman Khapov
| Attachment | Content-Type | Size |
|---|---|---|
| 0001-use-_LAST-in-enums-to-define-NUM-macross.patch | application/octet-stream | 4.2 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew Dunstan | 2025-11-18 13:59:20 | Re: Running a single test |
| Previous Message | Peter Eisentraut | 2025-11-18 13:35:59 | Re: alignas (C11) |