From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, David Rowley <dgrowleyml(at)gmail(dot)com> |
Subject: | Re: Remove fls(), use pg_bitutils.h facilities instead? |
Date: | 2022-07-20 04:52:54 |
Message-ID: | 1596564.1658292774@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Thomas Munro <thomas(dot)munro(at)gmail(dot)com> writes:
> Back in commit 4f658dc8 we gained src/port/fls.c. As anticipated by
> its commit message, we later finished up with something better in
> src/include/port/pg_bitutils.h. fls() ("find last set") is an
> off-by-one cousin of pg_leftmost_one_pos32(). I don't know why ffs()
> ("find first set", the rightmost variant) made it into POSIX while
> fls() did not, other than perhaps its more amusing name. fls() is
> present on *BSD, Macs and maybe more, but not everywhere, hence the
> configure test. Let's just do it with pg_bitutils.h instead, and drop
> some cruft? Open to better ideas on whether we need a new function,
I think we could probably just drop fls() entirely. It doesn't look
to me like any of the existing callers expect a zero argument, so they
could be converted to use pg_leftmost_one_pos32() pretty trivially.
I don't see that fls() is buying us anything that is worth requiring
readers to know yet another nonstandard function.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Fujii Masao | 2022-07-20 05:00:00 | Re: Backup command and functions can cause assertion failure and segmentation fault |
Previous Message | Junwang Zhao | 2022-07-20 04:51:24 | Re: Memory leak fix in psql |