On Mon, 3 Jun 2024 at 15:58, Peter Maydell <peter.mayd...@linaro.org> wrote: > > On Mon, 3 Jun 2024 at 15:49, Daniel P. Berrangé <berra...@redhat.com> wrote: > > We can't rely on the sanitizers to catch all cases where we're casting > > functions, as we don't have good enough code coverage in tests to > > identify all places that way. > > > > Unless there's a warning flag we can use to get diagnosis of this > > problem at compile time and then fix all reported issues, I won't have > > any confidence in our ability to remove > > -fsanitize-cfi-icall-generalize-pointers > > for CFI. > > You might think that -Wcast-function-type would detect them at compile > time, but that has two loopholes: > 1. void(*) (void) matches everything > 2. any parameter of pointer type matches any other pointer type > > It seems to me rather inconsistent that the sanitizers do > not match up with the warning semantics here. I think I > would vote for raising that with the compiler folks -- > either the sanitizer should be made looser so it matches > the -Wcast-function-type semantics, or else a new tighter > warning option that matches the sanitizer should be > provided. Ideally both, I think. But it's definitely silly > to have a runtime check that flags up things that the > compiler perfectly well could detect at compile time but > is choosing not to.
Slightly further investigation suggests clang 16 and later have -Wcast-function-type-strict for the "report all the same casts that the sanitizer does". gcc doesn't I think have that yet. I didn't spot any option in the sanitizer to loosen the set of things it considers mismatched function pointers. -- PMM
