Bug 109835 - -Wincompatible-function-pointer-types as a subset of -Wincompatible-pointer-types?
Summary: -Wincompatible-function-pointer-types as a subset of -Wincompatible-pointer-t...
Status: UNCONFIRMED
Alias: None
Product: gcc
Classification: Unclassified
Component: c (show other bugs)
Version: 14.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: diagnostic
Depends on:
Blocks: new-warning, new_warning
  Show dependency treegraph
 
Reported: 2023-05-12 16:18 UTC by Sam James
Modified: 2024-03-22 22:43 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sam James 2023-05-12 16:18:40 UTC
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.
Comment 1 Florian Weimer 2023-05-12 16:49:19 UTC
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.
Comment 2 Sam James 2023-05-12 21:13:25 UTC
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.
Comment 3 Eric Gallager 2023-05-13 15:05:10 UTC
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...
Comment 4 Sam James 2023-05-13 22:56:07 UTC
(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.
Comment 5 Sam James 2024-03-22 14:12:03 UTC
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).
Comment 6 Eric Gallager 2024-03-22 22:43:09 UTC
(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.