Re: Remove traces of long in dynahash.c - Mailing list pgsql-hackers

From Chao Li
Subject Re: Remove traces of long in dynahash.c
Date
Msg-id EF97A695-B0A7-4DB6-9D15-B88062B7D6E5@gmail.com
Whole thread Raw
In response to Re: Remove traces of long in dynahash.c  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Remove traces of long in dynahash.c
List pgsql-hackers


On Aug 20, 2025, at 15:40, Michael Paquier <michael@paquier.xyz> wrote:

On Tue, Aug 19, 2025 at 10:46:58AM -0400, Tom Lane wrote:
+1 for getting rid of those while we're doing janitorial work here.
They're not *quite* duplicates though, for instance next_pow2_int has
different response to out-of-range values than pg_nextpower2_32.

This would mean introducing more flavors in pg_bitutils.h with limit
checks.  That does not seem completely right to do in this file, which
is a wrapper for all the __builtin_*() calls?  A second point is on
the signedness but we could just cap the maximum at
(PG_UINT{32,64}_MAX / 2), I guess, with two new routines like:
uint64 pg_nextpower2_64_max(uint64 num);
uint32 pg_prevpower2_32_max(uint32 num);


I wonder if we can keep the same naming style to make the new function name like next_pow2_64()?

--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/




pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: ReplicationSlotRelease() crashes when the instance is in the single user mode
Next
From: Kirill Reshke
Date:
Subject: Re: IPC/MultixactCreation on the Standby server