Bug 15763 - ldb fails to build with clang
Summary: ldb fails to build with clang
Status: NEW
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: Build (show other bugs)
Version: 4.21.2
Hardware: All All
: P5 normal (vote)
Target Milestone: ---
Assignee: Samba QA Contact
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-12-07 12:58 UTC by Mohamed Akram
Modified: 2025-03-09 20:55 UTC (History)
1 user (show)

See Also:


Attachments
possible patch (951 bytes, patch)
2024-12-08 22:22 UTC, Douglas Bagnall
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mohamed Akram 2024-12-07 12:58:33 UTC
I'm getting these errors when building on macOS:

  ../../lib/ldb/tests/test_ldb_comparison_fold.c:58:2: error: initializer element is not a compile-time constant
     58 |         STR_VAL("", 0),
        |         ^~~~~~~~~~~~~~

  ../../lib/ldb/tests/test_ldb_comparison_fold.c:80:2: error: initializer element is not a compile-time constant
     80 |         STR_VAL(" a", 1),
        |         ^~~~~~~~~~~~~~~~

  ../../lib/ldb/tests/test_ldb_comparison_fold.c:96:2: error: initializer element is not a compile-time constant
     96 |         STR_VAL(" a", 1),
        |         ^~~~~~~~~~~~~~~~
Comment 1 Douglas Bagnall 2024-12-08 22:22:04 UTC
Created attachment 18506 [details]
possible patch

Are you able to apply this patch? does it help?
Comment 2 Mohamed Akram 2024-12-09 20:43:47 UTC
Yup, that works, thanks.
Comment 3 Douglas Bagnall 2025-03-06 20:35:26 UTC
(In reply to Douglas Bagnall from comment #1)

The trouble with this patch

-#define STR_VAL(s, r) { { discard_const(s), sizeof(s) - 1 }, r}
+#define STR_VAL(s, r) { { (char *)(s), sizeof(s) - 1 }, r}

is with clang 15 we get [1]:

../../lib/ldb/tests/test_ldb_comparison_fold.c:55:27: error: pointer targets in initialization of ‘uint8_t *’ {aka ‘unsigned char *’} from ‘char *’ differ in signedness [-Werror=pointer-sign]
   55 | #define STR_VAL(s, r) { { (char *)(s), sizeof(s) - 1 }, r}
      |                           ^
../../lib/ldb/tests/test_ldb_comparison_fold.c:108:9: note: in expansion of macro ‘STR_VAL’
  108 |         STR_VAL("\xff\xfe", 1000),
      |         ^~~~~~~
../../lib/ldb/tests/test_ldb_comparison_fold.c:55:27: note: (near initialization for ‘values_utf8[9].val.data’)
   55 | #define STR_VAL(s, r) { { (char *)(s), sizeof(s) - 1 }, r}
      |                           ^
../../lib/ldb/tests/test_ldb_comparison_fold.c:108:9: note: in expansion of macro ‘STR_VAL’
  108 |         STR_VAL("\xff\xfe", 1000),
      |         ^~~~~~~


[1] https://cdn.artifacts.gitlab-static.net/d7/74/d774f54988aa2cb1f213a2c33407ff6a6b6e5e8de9a78fa29204f25918db3517/2025_03_06/9327802626/10373753081/job.log?response-content-type=text%2Fplain%3B%20charset%3Dutf-8&response-content-disposition=inline&Expires=1741292851&KeyName=gprd-artifacts-cdn&Signature=wmjMPmwmaqPFyardbTqk8zh6Z3k=

Obviously if we change it to 

#define STR_VAL(s, r) { { (uint8_t *)(s), sizeof(s) - 1 }, r}

we fix one error, but if we go to 

#define STR_VAL(s, r) { { (uint8_t *)((uintptr_t)(s)), sizeof(s) - 1 }, r}

to solve the other one, we end up more or less where discard_const() put us, which was apparently too much indirection for the Mac compiler to see that the value was constant.


What compiler are you using?
Comment 4 Mohamed Akram 2025-03-09 19:02:20 UTC
(In reply to Douglas Bagnall from comment #3)

I believe I used Clang 15 which comes with macOS. I added your patch to MacPorts and I just checked a recent log and it does build fine - https://build.macports.org/builders/ports-14_x86_64-builder/builds/54864/steps/install-port/logs/stdio.

There's no error, just a warning:

../../lib/ldb/tests/test_ldb_comparison_fold.c:76:2: warning: initializing 'uint8_t *' (aka 'unsigned char *') with an expression of type 'char *' converts between pointers to integer types where one is of the unique plain 'char' type and the other is not [-Wpointer-sign]
        STR_VAL("\xff\xfe", 1000),

Also builds with Clang 16 for me.
Comment 5 Douglas Bagnall 2025-03-09 20:55:42 UTC
(In reply to Mohamed Akram from comment #4)
Yeah, the difference is that our CI builds use a debug mode that turns on warnings and -Werror (i.e. warnings become errors).

Maybe we just have to quietly leave things as they are, with that patch in MacPorts but not upstream.

It makes me wonder how other clang-based systems manage this.