Re: Don't cast away const where possible

From: Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>
To: Peter Eisentraut <peter(at)eisentraut(dot)org>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Don't cast away const where possible
Date: 2025-12-31 08:42:48
Message-ID: aVTiCHBalaFCneYD@ip-10-97-1-34.eu-west-3.compute.internal
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On Mon, Dec 29, 2025 at 09:01:46AM +0000, Bertrand Drouvot wrote:
> Hi,
>
> On Mon, Dec 22, 2025 at 12:53:03PM +0100, Peter Eisentraut wrote:
> > On 18.12.25 14:55, Bertrand Drouvot wrote:
> > > Some functions are casting away the const qualifiers from their signatures in
> > > local variables.
> >
> > @@ -1304,8 +1304,8 @@ merge_overlapping_ranges(FmgrInfo *cmp, Oid colloid,
> > static int
> > compare_distances(const void *a, const void *b)
> > {
> > - DistanceValue *da = (DistanceValue *) a;
> > - DistanceValue *db = (DistanceValue *) b;
> > + const DistanceValue *da = (const DistanceValue *) a;
> > + const DistanceValue *db = (const DistanceValue *) b;
> >
> > I wonder if the better fix here wouldn't be to get rid of the cast. It's not
> > necessary, and without it the compiler would automatically warn about
> > qualifier mismatches.
>
> Yeah, that looks better as it provides an extra safety check should the function
> signature change.

Out of curiosity, I searched for places where we could remove explicit casts when
assigning from void pointers (relying on implicit conversion instead), that would
lead to:

"
157 files changed, 387 insertions(+), 388 deletions(-)
"

That's not a small patch and I think that doing this work is valuable though.

We could imagine, working on say 20 files at a time and say once per month.
That would ease the review(s) and also avoid too many rebases for patches waiting
in the commitfest.

Thoughts?

Regards,

--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2025-12-31 08:47:32 PL/Python initialization cleanup
Previous Message Chao Li 2025-12-31 08:15:49 nbtree: Cache operator family OID in _bt_setup_array_cmp