On 03.09.25 13:42, Daniel Gustafsson wrote:
On 3 Sep 2025, at 07:47, Peter Eisentraut <pe...@eisentraut.org> wrote:
- Hundreds of compiler warnings (They are not necessarily wrong, but it shows
that no one has taken care to tune the warnings or the code in any way
recently.)
Should these be posted somewhere before they are lost in case anyone is keen on
digging through the list for any relevant fixes?
That would require me to figure out how to export files from this VM.
;-) But I did figure out how to copy and paste, so here is at least a
summary:
1 (E_ARG_INCOMPATIBLE_WITH_ARG_L)
16 (E_ASSIGNMENT_TYPE_MISMATCH)
1 (E_CONST_OBJ_SHOULD_HAVE_INITIZR)
24 (E_CONST_PROMOTED_LONG_LONG)
1 (E_EMPTY_DECLARATION)
1899 (E_END_OF_LOOP_CODE_NOT_REACHED)
22 (E_FUNC_NO_RET_RET)
2 (E_INTEGER_OVERFLOW_DETECTED)
23 (E_L_OPERAND_DOT_NOT_LVALUE_NOW)
2 (E_OPERANDS_INCOMPATIBLE_TYPES)
1 (E_REF_STATIC_EXTERN_INLINE)
714 (E_STATEMENT_NOT_REACHED)
435 (E_STRUCT_DERIVED_FROM_FLEX_MBR)
Most of these as you can see are from lack of understanding about flow
control annotations or conventions.
But there are a couple of interesting ones:
1 (E_EMPTY_DECLARATION)
This is actually a real find, albeit harmless:
```
diff --git a/src/backend/replication/logical/slotsync.c
b/src/backend/replication/logical/slotsync.c
index 9d0072a49ed..8c061d55bdb 100644
--- a/src/backend/replication/logical/slotsync.c
+++ b/src/backend/replication/logical/slotsync.c
@@ -1337,7 +1337,7 @@ reset_syncing_flag()
SpinLockRelease(&SlotSyncCtx->mutex);
syncing_slots = false;
-};
+}
/*
* The main loop of our worker process.
```
2 (E_INTEGER_OVERFLOW_DETECTED)
This complains about lwlock.c
StaticAssertDecl((MAX_BACKENDS & LW_FLAG_MASK) == 0,
"MAX_BACKENDS and LW_FLAG_MASK overlap");
StaticAssertDecl((LW_VAL_EXCLUSIVE & LW_FLAG_MASK) == 0,
"LW_VAL_EXCLUSIVE and LW_FLAG_MASK overlap");
Here, MAX_BACKENDS is of type unsigned int and LW_FLAG_MASK is of type
signed int. (LW_VAL_EXCLUSIVE is computed from MAX_BACKENDS and is also
unsigned int.) The & operation promotes both to unsigned int, and so it
thinks you might get an overflow of the LW_FLAG_MASK value?
I can make the warning go away with this:
diff --git a/src/backend/storage/lmgr/lwlock.c
b/src/backend/storage/lmgr/lwlock.c
index a4aecd1fbc3..667ed4cf699 100644
--- a/src/backend/storage/lmgr/lwlock.c
+++ b/src/backend/storage/lmgr/lwlock.c
@@ -95,7 +95,7 @@
#define LW_FLAG_RELEASE_OK ((uint32) 1 << 30)
#define LW_FLAG_LOCKED ((uint32) 1 << 29)
#define LW_FLAG_BITS 3
-#define LW_FLAG_MASK
(((1<<LW_FLAG_BITS)-1)<<(32-LW_FLAG_BITS))
+#define LW_FLAG_MASK
(((1U<<LW_FLAG_BITS)-1)<<(32-LW_FLAG_BITS))
/* assumes MAX_BACKENDS is a (power of 2) - 1, checked below */
#define LW_VAL_EXCLUSIVE (MAX_BACKENDS + 1)
I can't reproduce this with gcc by removing -fwrapv and dialing up the
-Wstrict-overflow= levels. And I also don't want to think about what
this double-shift expression even means. :-/
But intuitively, it seems better if a "mask" value has an unsigned type.
I don't know to what extent PostgreSQL can even survive in a non-fwrapv
environment. That's a larger philosophical question.
