Linux: Clang build fixes by robn · Pull Request #17954 · openzfs/zfs

robn · 2025-11-19T11:59:05Z

Motivation and Context

Recent Clang is a little upset with a handful of things on the Linux side. This sorts it out.

Fixes #17951
Fixes #17959

Description

See commit messages. Summary:

Linux: don't explicitly declare -std=gnu99
zvol_id: make array length properly known at compile time
config/kmap_atomic: initialise test data

How Has This Been Tested?

Compiled and basic sanity runs done with GCC 14.2 and Clang 17, 19 and 22 against Linux 6.1.x, 6.16.x and 6.18-rc.

Not my usual comprehensive set, but recompiling kernels as well adds a lot of time and building with Clang is more difficult the older they get.

Types of changes

Bug fix (non-breaking change which fixes an issue)
New feature (non-breaking change which adds functionality)
Performance enhancement (non-breaking change which improves efficiency)
Code cleanup (non-breaking change which makes code smaller or more readable)
Quality assurance (non-breaking change which makes the code more robust against bugs)
Breaking change (fix or feature that would cause existing functionality to change)
Library ABI change (libzfs, libzfs_core, libnvpair, libuutil and libzfsbootenv)
Documentation (a change to man pages or other documentation)

Checklist:

My code follows the OpenZFS code style requirements.
I have updated the documentation accordingly.
I have read the contributing document.
I have added tests to cover my changes.
I have run the ZFS Test Suite with this change applied.
All commit messages are properly formatted and contain Signed-off-by.

Linux switched from -std=gnu89 to -std=gnu11 in 5.18 (torvalds/linux@e8c07082a810f). We've always overridden that with gnu99 because we use some newer features. More recent kernels are using C11 features in headers that we include. GCC generally doesn't seem to care, but more recent versions of Clang seem to be enforcing our gnu99 override more strictly, which breaks the build in some configurations. Just bumping our "override" to match the kernel seems to be the easiest workaround. It's an effective no-op since 5.18, while still allowing us to build on older kernels. Sponsored-by: https://despairlabs.com/sponsor/ Signed-off-by: Rob Norris <robn@despairlabs.com>

Using strlen() in an static array declaration is a GCC extension. Clang calls it "gnu-folding-constant" and warns about it, which breaks the build. If it were widespread we could just turn off the warning, but since there's only one case, lets just change the array to an explicit size. Sponsored-by: https://despairlabs.com/sponsor/ Signed-off-by: Rob Norris <robn@despairlabs.com>

6.18 changes kmap_atomic() to take a const pointer. This is no problem for the places we use it, but Clang fails the test due to a warning about being unable to guarantee that uninitialised data will definitely not change. Easily solved by forcibly initialising it. Sponsored-by: https://despairlabs.com/sponsor/ Signed-off-by: Rob Norris <robn@despairlabs.com>

JohnyPeaN · 2025-11-19T21:48:25Z

Tested it without the -std=gnu99 and now with -std=gnu11 change and both work. Solves the #17951, thanks.

behlendorf

Assuming the CI gives it a clean bill of health this looks good.

alex-moch · 2025-11-21T18:24:46Z

This does not fix #17959 for me. #17684 fixes the build with LLVM/Clang 21 on 2.2.9 and 2.3.5.

Using strlen() in an static array declaration is a GCC extension. Clang calls it "gnu-folding-constant" and warns about it, which breaks the build. If it were widespread we could just turn off the warning, but since there's only one case, lets just change the array to an explicit size. Sponsored-by: https://despairlabs.com/sponsor/ Reviewed-by: Alexander Motin <alexander.motin@TrueNAS.com> Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Signed-off-by: Rob Norris <robn@despairlabs.com> Closes #17954

6.18 changes kmap_atomic() to take a const pointer. This is no problem for the places we use it, but Clang fails the test due to a warning about being unable to guarantee that uninitialised data will definitely not change. Easily solved by forcibly initialising it. Sponsored-by: https://despairlabs.com/sponsor/ Reviewed-by: Alexander Motin <alexander.motin@TrueNAS.com> Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Signed-off-by: Rob Norris <robn@despairlabs.com> Closes #17954

Linux switched from -std=gnu89 to -std=gnu11 in 5.18 (torvalds/linux@e8c07082a810f). We've always overridden that with gnu99 because we use some newer features. More recent kernels are using C11 features in headers that we include. GCC generally doesn't seem to care, but more recent versions of Clang seem to be enforcing our gnu99 override more strictly, which breaks the build in some configurations. Just bumping our "override" to match the kernel seems to be the easiest workaround. It's an effective no-op since 5.18, while still allowing us to build on older kernels. Sponsored-by: https://despairlabs.com/sponsor/ Reviewed-by: Alexander Motin <alexander.motin@TrueNAS.com> Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Signed-off-by: Rob Norris <robn@despairlabs.com> Closes openzfs#17954

Using strlen() in an static array declaration is a GCC extension. Clang calls it "gnu-folding-constant" and warns about it, which breaks the build. If it were widespread we could just turn off the warning, but since there's only one case, lets just change the array to an explicit size. Sponsored-by: https://despairlabs.com/sponsor/ Reviewed-by: Alexander Motin <alexander.motin@TrueNAS.com> Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Signed-off-by: Rob Norris <robn@despairlabs.com> Closes openzfs#17954

6.18 changes kmap_atomic() to take a const pointer. This is no problem for the places we use it, but Clang fails the test due to a warning about being unable to guarantee that uninitialised data will definitely not change. Easily solved by forcibly initialising it. Sponsored-by: https://despairlabs.com/sponsor/ Reviewed-by: Alexander Motin <alexander.motin@TrueNAS.com> Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Signed-off-by: Rob Norris <robn@despairlabs.com> Closes openzfs#17954