Fix conversion warnings in headers
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t253414psql -h localhost -U postgresBuilt from patchset v1 (message #1), October 22, 2026 at 09:27 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t253414_1 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t253414_1 && git checkout t253414_1Patchset v1 (message #1) is on t253414_1
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.
- Andrew
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.