Re: Remove useless casting to the same type

From: Peter Eisentraut <peter(at)eisentraut(dot)org>
To: Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>, Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Remove useless casting to the same type
Date: 2025-11-28 08:17:20
Message-ID: 501e36a2-534b-409c-a86e-08e742d5c388@eisentraut.org
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 25.11.25 06:46, Bertrand Drouvot wrote:
>> Hm. How do we feel, as a group, about superstitious casts in variadic
>> calls? I don't feel like they're in the same class as the other fixes.
>>
>> Argument for: it's nice to know at a glance that a printf() invocation
>> won't corrupt something horribly, especially if I'm quickly scanning
>> code during a CVE analysis, and especially if the variable is named as
>> if it could maybe be a size_t. Do our compilers warn us well enough
>> now, in practice?
>>
>> Argument against: it takes up precious columns and focuses attention
>> away from other things.
> Thanks for looking at it!
>
> I think that the variadic calls in the patch are related to functions that
> can benefits from -Wformat. Let's focus on those: with the cast one would need
> to verify 3 things: variable type, cast and format specifier.
> Without the cast then only 2 things and the compiler can verify these match via
> -Wformat warnings.
>
> With the cast, the compiler only checks that the cast result matches the format,
> not whether the cast itself is correct, so I'm in favor of removing the cast,
> thoughts?

Yes, I think with -Wformat you get approximately the same level of
protection as with a prototype.

>> Like the fact that (items->nitem -
>> items->curitem - maxitems) is unsigned and printed as signed here. :D
> Nice catch! ;-)
>
>> Maybe we should make the code compile cleanly under
>> -Wformat-signedness at some point...

That would be similar to using -Wsign-conversion with function
prototypes. Maybe a good idea, but we don't use it, and so we shouldn't
expect it for non-prototype invocations either.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Nazir Bilal Yavuz 2025-11-28 08:27:11 Re: Add pg_buffercache_mark_dirty[_all] functions to the pg_buffercache
Previous Message Chao Li 2025-11-28 08:16:59 Cleanup shadows variable warnings, round 1