[PATCH] D131351: [C] Default implicit function pointer conversions diagnostic to be an error

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

In D131351#3714968 <https://reviews.llvm.org/D131351#3714968>, @brooksmoses wrote:

> For the record, so far we've seen this showing up in the following:
>
> - A case in a notoriously warning-heavy third-party library where we'd backported a file from a newer version and didn't quite fix all the internal API mismatches.
> - A ten-year-old bug in a local patch to another third-party library, where a function-pointer parameter was defined as returning a `void` and then assigned to a function-pointer that returns a `void *`.
> - A probably-innocuous bug in a local patch to yet another third-party library, where we were passing an `int foo(char *, char *)` function to GLIBC's `qsort`, which expects a function with a signature of `int foo(void *, void *)`.
> - A case where https://gitlab.freedesktop.org/pixman/pixman/-/commit/e0d4403e78a7af8f4be4110ae25e9c3d1ac93a78 wasn't applied to our local version.  This is also probably an innocuous case, not a "real" bug.
> - A case where SciPy's extension has a function that uses `void *` for a `FILE *` pointer (https://github.com/scipy/scipy/blob/main/scipy/spatial/_qhull.pyx#L187, second argument) while the corresponding C code's function has a real `FILE *` pointer (https://github.com/qhull/qhull/blob/master/src/libqhull_r/io_r.h#L97).  The SciPy function also uses a `void *` for an argument of a struct type, which seems rather odd to me given that it just defined the type two lines earlier.
>
> So, real bugs in 40% of cases, I'd say.

I double-checked these scenarios against the standard (where possible) and all of them are undefined behavior per the spec (and would be things I would expect a type sanitizer to report on), but I agree that not all of them seem likely to lead to a security vulnerability.

In D131351#3714993 <https://reviews.llvm.org/D131351#3714993>, @MaskRay wrote:

> Nit: I think it is useful mentioning `-Wincompatible-pointer-types``-Wincompatible-function-pointer-types` in the commit message, not just in `clang/docs/ReleaseNotes.rst`, so that `git log --grep incompatible-function-pointer-types` will reveal something when the user knows incompatible-function-pointer-types but not "implicit function pointer conversions diagnostic".

Good point, thanks!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D131351/new/

https://reviews.llvm.org/D131351