From: Adrian Ratiu Date: Sun, 11 Jan 2026 14:20:36 GMT Subject: Re: [Bug] hook: -Wanalyzer-deref-before-check warning in run_hooks_opt Message-ID: <87bjj0s023.fsf@collabora.com> In-Reply-To: On Fri, 09 Jan 2026, "brian m. carlson" wrote: > On 2026-01-09 at 11:31:10, Patrick Steinhardt wrote: >> It's not a real bug. If you take a look at the the `if (!options)` >> check, you'll see: >> >> if (!options) >> BUG("a struct run_hooks_opt must be provided to run_hooks"); >> >> So we'd abort immediatly with an error message in case the pointer was >> `NULL`. Which clarifies that this is a case that shouldn't ever happen >> in the first place. > > You might think that we'd abort, but that's not what modern compilers > do. Dereferencing `options` if it is NULL is undefined behaviour. > Compilers are free to assume that undefined behaviour never happens, so > what most modern compilers do is say, "Oh, we've dereferenced `options`, > so it can never be NULL," and then use that to omit the check > altogether. > > This sounds bizarre and like it might actually lead to security bugs, > and you're right. However, compilers keep wanting to make code go > faster, so they keep relying on eliminating undefined behaviour to make > more assumptions about the code to optimize it, even if that results in > code that doesn't do what the programmer intended. > > This is one of the reasons why I'm in favour of writing more Rust, since > safe Rust doesn't have undefined behaviour and therefore doesn't suffer > from these problems. > > In any event, this is almost certainly a bug because it almost certainly > does not do what it looks like it does and the compiler is right to warn > about it. Ack and thanks for the feedback. 100% agreed on writing more Rust. :) See the below link for the fix. I've ensured the NULL check happens before dereferencing (many thanks to Patrick as well). https://lore.kernel.org/git/87ecnws0fx.fsf@gentoo.mail-host-address-is-not-set/T/#ma8343d1b5393d4efc0c1103357a6e684fc8b1017