Error building with clang 21.1.8 On Debian testing

[fxlb]

• This is not a security issue (See first line).

Debian testing (Forky)

uname -a

Linux ec0ffc8ba5c5 6.1.0-41-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.158-1 (2025-11-09) x86_64 GNU/Linux

clang --version

Debian clang version 21.1.8 (1+b1)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/lib/llvm-21/bin

CC=clang ./build.sh

[...]
$ make -s testprogs CFLAGS=-Werror
./valgrindtest.c:407:53: error: variable 'bad_fcode' is
      uninitialized when passed as a const pointer argument here
      [-Werror,-Wuninitialized-const-pointer]
  407 |         setsockopt(pcap_fd, SOL_SOCKET, SO_ATTACH_FILTER, &bad_fcode,
      |                                                            ^~~~~~~~~
1 error generated.
make[1]: *** [Makefile:158: valgrindtest] Error 1
make: *** [Makefile:561: testprogs] Error 2

[infrastation]

The same problem does not reproduce on FreeBSD 15.0 with Clang 21.2, but reproduces on Alpine Linux 3.23 with Clang 21.2.

[guyharris]

The same problem does not reproduce on FreeBSD 15.0

The prototype of ioctl(), which is what's used in tha code path on platforms with BPF as the capture mechanism, is int ioctl(int, unsigned long, ...) (presumably to allow ioctls that don't use a parameter to omit the parameter argument), so the compiler doesn't know whether the ioctl will modify bad_fprog or not.

... but reproduces on Alpine Linux 3.23 with Clang 21.2.

The prototype of setsockopt(), which is what's used in the code path for Linux, is int setsockopt(int, int, int, const void *, socklen_t), so the compiler does know that.

And the whole point of this test is not to initialize it, as we're testing to make sure that valgrind will complain that the structure isn't initialized - see the comment before the ioctl()/setsockopt() code.

To quote the commit message:

commit ed88379764e5bfa754df224d6293793c0802654b
Author: Guy Harris <gharris@sonic.net>
Date:   Wed Apr 10 15:43:11 2013 -0700

    Add a test program for the open, close, and filter compile/set code paths.
    
    This is to test for both libpcap bugs *and* Valgrind bugs; Valgrind on
    OS X (and probably other systems using BPF) and Linux reports bogus
    errors when setting a filter (because it blindly checks that the
    *entire* bpf_program structure for BIOCSETF and the *entire* sock_fprog
    structure for setsockopt(SOL_SOCKET, SO_ATTACH_FILTER) has been
    initialized, rather than checking only the structure members and not the
    padding, and *doesn't* check whether the program *pointed to* by that
    structure has been initialized).  See
    
            https://bugs.kde.org/show_bug.cgi?id=312989
    
    (I'll be filing a similar bug, with a similar patch to fix it, for
    Valgrind-on-Linux).

This was provoked by people submitting issues for tcpdump complaining that valgrind was complaining about uninitialized data being passed to ioctl()/setsockopt() - my fixes were to have valgrind not check the padding (as it doesn't affect what the kernel does) and check the BPF program to make sure it's initialized (as it does affect what the kernel does).

The reason why we're directly using ioctl() and setsockopt() is explained in a later commit:

commit e6408a8ca29502f8069b3b620f1bd13600ee795e
Author: Guy Harris <gharris@sonic.net>
Date:   Wed Apr 10 16:11:41 2013 -0700

    Use raw ioctls or setsockopts to set the bad filters.
    
    That guarantees that libpcap doesn't test the filter and decide the
    kernel can't handle it, or attempt to fix it to work as a kernel filter,
    and also avoids warnings from libpcap looking at the filter rather than
    the system call looking at the filter.

So this program is expected to fail when run under valgrind, but it's expected to fail in a certain way.

To suppress the warning (for intentionally bad code), we could add stuff to diag-control.h to explicitly suppress that warning (PCAP_DO_PRAGMA(clang diagnostic ignored "-Wuninitialized-const-pointer")) and wrap DIAG_OFF_UNINITIALIZED_CONST_POINTER and DIAG_ON_UNINITIALIZED_CONST_POINTER around that code fragment.

[infrastation]

Thank you for explaining. If you need linux-aarch64 upgraded to Clang 21, let me know.

[fxlb]

Thank you for this analysis.