nickdesaulniers added a comment.

In D134461#3815458 <https://reviews.llvm.org/D134461#3815458>, @aaron.ballman 
wrote:

> In D134461#3815298 <https://reviews.llvm.org/D134461#3815298>, @nathanchance 
> wrote:
>
>> This warning is quite noisy for the Linux kernel due to a couple of places 
>> where a `void *` is dereferenced as part of compile time checking.
>
> Thank you for letting us know!

In particular offsetof and __is_constexpr are _heavily_ used throughout the 
codebase.

> This one is interesting to me -- I was on the fence about whether we want to 
> diagnose this in an unevaluated context or not. The 
> `clang/test/Analysis/misc-ps.m` test was why I was considering it, and I 
> eventually convinced myself that the dereference there was a harmless UB when 
> we support pointer arithmetic on void as an extension, but UB nonetheless. 
> Now I wonder whether we want different behavior in the `sizeof` case -- it 
> seems odd to me that we warn by default on `sizeof(*vp)` but not 
> `sizeof(void)`: https://godbolt.org/z/PcMrW7b5W so I think we might want to 
> silence `sizeof(*vp)` diagnostics.
>
> WDYT?

SGTM

> All this said, I think in both cases we want `-pedantic` to warn on these 
> situations even if we would silence by default. e.g.,
>
>   void func(void *vp) {
>     sizeof(void); // No warning by default, does get pedantic warning
>     sizeof(*vp); // No warning by default, does get pedantic warning
>     sizeof(*(vp))`; // No warning by default, does get pedantic warning
>     void inner(typeof(*vp)); // No warning by default, does get pedantic 
> warning
>   
>     (void)*vp; // Warning by default
>   }
>
> What do folks think of that idea?

SGTM; either warn via -Wpedantic or silenced with -Wno-gnu.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D134461

_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to