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
0001-use-_LAST-in-enums-to-define-NUM-macross.patch
Description: Binary data
