On 2026-08-13 Bruno Haible via Gnulib discussion list wrote: > > After upgrading the CI to use a newer clang for the check with > > sanitizers, I see a couple of runtime errors: > > And similarly in libtextstyle. Here it is because some function > prototypes take a 'struct term_style_user_data *' parameter, whereas > in some compilation unit there is a > #define term_style_user_data foobar > such that the function prototypes here take a 'struct foobar *' > parameter. This is intentional use of a generic / user-definable > type. This patch silences the errors.
These sanitizer errors mean that the program cannot be compiled with strict forms of control flow integrity checking. It can be done in software (clang -flto -fsanitize=cfi -fvisibility=hidden) or with hardware assist. On x86-64, there is indirect branch tracking (IBT). When enabled, any indirect jump must land on an ENDBR64 instruction or the program will crash. It doesn't care about the function prototypes, so this hardware feature isn't strict. On RISC-V, there is the Zicfilp extension with the LPAD instruction.[1] It can be used to implement strict checking. For example, a hash of the function return type and the types of the arguments can be calculated at compile time. Before an indirect jump, the hash value is loaded in register x7. The jump must land on a LPAD instruction that contains the same hash value. Otherwise the program will crash. It might be annoying to fix these sanitizer errors, but I think it's worth doing at some point. In this case toolchains are taking advantange of undefined behavior to improve security. [1] https://docs.riscv.org/reference/isa/v20260120/unpriv/unpriv-cfi.html#unpriv-forward -- Lasse Collin
