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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
