Re: Solaris compiler status - Mailing list pgsql-hackers

On 03.09.25 13:42, Daniel Gustafsson wrote:
>> On 3 Sep 2025, at 07:47, Peter Eisentraut <peter@eisentraut.org> wrote:
> 
>> - Hundreds of compiler warnings (They are not necessarily wrong, but it shows that no one has taken care to tune the
warningsor 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.