wrt the C changes we're planning for 14 (https://gcc.gnu.org/pipermail/gcc/2023-May/241264.html, https://gcc.gnu.org/pipermail/gcc/2023-May/241502.html): GCC has -Wincompatible-pointer-types which is a bit noisier than -Wincompatible-function-pointer-types which Clang also provides. Example which should emit the prosp. new warning: ``` void func(const int *i); void other(void) { void (*fp)(int *) = func; // Emits -Wincompatible-function-pointer-types } ``` Example which shouldn't, but should emit -Wincompatible-pointer-types: ``` void other(void) { int* x; unsigned int* y = &x; // Emits -Wincompatible-pointer-types } ``` Note that function pointers are a bit more interesting in that you need this fixed for CFI and the bugs tend to be more notable (although there's still const-correctness noise). -Wincompatible-pointer-types is still a sin but so far, looks noisier to me.
Presumably the idea is to enable -Werror=incompatible-function-pointer-types (in spirit) because it is more severe than -Wincompatible-pointer-types? I'm not sure this is actually true. Your first example will not have ABI problems or strict-aliasing issues. It seems rather harmless. Your second example (even with “int x;” instead, which we do not warn about by default) is likely to introduce strict-aliasing issues (obviously not in this minimal fragment, but still). If we want to error on incompatible-function-pointer-types by default, I think we need to make some effort to refine what such incompatible function pointers should be.
Okay, fair point, I gave examples but not *motivating* examples. I have some non-harmless examples: 1. https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=1e0e5c4d289004fa779c86da9319cf2bb18548b1 (a nasty one) 2. https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=71ae0b143a55fd45d4fd56cff13438cdbc602089 (sort example) 3. https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=996809c0e52057ec8e5f32dd1d9f8f9bea559c18 (interesting example wrt attributes) 4. https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=573dae0ef553e180e7f5c85a333adce34237f59b (completely wrong) I can dig some more for general examples I've seen, but I tried to pick out those above w/ different characteristics. I've seen a lot of e.g. qsort mismatched signatures but struggled for a bit with finding ABI concerns (SA I feel is something which is hard to manifest as a problem here because you need that "second order" manipulation which isn't that common.) But David Seifert (cc'd) came up with this wrt ABI: ``` #include <stdio.h> void fun(long long x, long long y) { printf("x = %lld, y = %lld\n", x, y); } void (*fun_ptr)(int, int) = fun; int main() { int x = 1; int y = 2; fun_ptr(x, y); } ``` ... which gives different results on x86_64-unknown-linux-gnu vs x86_64-unknown-linux-gnu -m32, but the only warning you get is -Wincompatible-pointer-types with GCC, rather than anything about the mismatch. I'll spend some more time reviewing -Wincompatible-pointer-types results when used on a global build but the last time I tried, it was unreasonably noisy given the other work we have ahead of us.
I thought that there was already a separate bug for this, but it turns out that I was thinking of bug 87379, which is for something different...
(In reply to Eric Gallager from comment #3) > I thought that there was already a separate bug for this, but it turns out > that I was thinking of bug 87379, which is for something different... Good catch. I think that'd actually address some (not all, ofc) of the concerns I have about these.
FWIW, after doing more of this work, I've decided I don't really care that much about this one. I still think FP mismatches are often worse, but there's enough junk pointer type mismatches that I'm not sure we should provide this (it's not like one case is OK and the other is way less scary or something).
(In reply to Sam James from comment #5) > FWIW, after doing more of this work, I've decided I don't really care that > much about this one. > > I still think FP mismatches are often worse, but there's enough junk pointer > type mismatches that I'm not sure we should provide this (it's not like one > case is OK and the other is way less scary or something). I mean, I might still use just one but not the other in a case where I've got a huge project, and need to narrow down the warnings so that I can just focus on a manageable subset, rather than being overwhelmed by having to try to look at all of them at once.