Re: [Bug] hook: -Wanalyzer-deref-before-check warning in run_hooks_opt

[Adrian Ratiu <adrian.ratiu@collabora.com>]

On Fri, 09 Jan 2026, "brian m. carlson" <sandals@crustytoothpaste.net> 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