| From: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
|---|---|
| To: | Andrew Kane <andrew(at)ankane(dot)org>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Fix conversion warnings in headers |
| Date: | 2026-09-23 09:00:28 |
| Message-ID: | 62833abe-a969-4198-8b8a-d5813c81e504@eisentraut.org |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 14.08.26 17:52, Andrew Kane wrote:
> When developing extensions, it can be useful to enable conversion
> warnings (`-Wconversion`). This patch fixes warnings in the headers so
> only warnings for the extension are shown.
I have tested this patch by running headerscheck with
EXTRAFLAGS='-Wconversion', and it appears to only silence a small subset
of those warnings across all header files. So this patch appears to be
incomplete, unless you had a different methodology in mind?
Independent of that, I don't think silencing these warnings by adding
more explicit casts everywhere is a good idea, because these casts could
hide other problems in the future. There is an arguably similar
undertaking where we have been replacing casts to remove qualifiers
(const, volatile) with explicit unconstify()/unvolatize() constructs
that are constructed so that they only permit the exact type
combinations that we want. I could imagine something similar here, like
- return VARSIZE(tup);
+ return iknowwhatimdoing_cast(uint32, Size, VARSIZE(tup));
Also, some of the proposed changes could possibly be avoided by making
changes to related definitions and interfaces. For example, instead of
- Assert((flags & ~SO_INTERNAL_FLAGS) == 0);
+ Assert((flags & (uint32) ~SO_INTERNAL_FLAGS) == 0);
we could make SO_INTERNAL_FLAGS have the right type to begin with.
And instead of
- int slen = strlen(str);
+ int slen = (int) strlen(str);
we should either make the lower-level code accept size_t cleanly or have
an explicit check that strlen(str) <= INT_MAX before doing this conversion.
Ultimately, I think we should be moving into a direction to handle all
of this more cleanly. But there is a lot more work to do for that.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Gleb Kashkin | 2026-09-23 09:11:56 | Re: Parameterized append subpaths |
| Previous Message | John Naylor | 2026-09-23 08:59:56 | Re: [PATCH] Refactor *_abbrev_convert() functions |