On Fri, Feb 19, 2021 at 2:15 PM Miguel Ojeda <miguel.ojeda.sandonis@xxxxxxxxx> wrote: > > On Fri, Feb 19, 2021 at 10:45 PM 'Nick Desaulniers' via Clang Built > Linux <clang-built-linux@xxxxxxxxxxxxxxxx> wrote: > > > > That said, I'm fine disabling this warning; there's a separate error > > for redefining a typedef to a different underlying type. That's > > what's useful IMO, this one really is not. > > > > This warning doesn't really provide any value to us in the kernel; I > > would guess the intent was to be helpful to code expected to be > > portable across different -std=* > > It seems it would also be useful to sport unintended cases, e.g.: > > - Collisions on short identifiers (that by chance typedef to the same type). > - Copy-pasting and forgetting to remove the original definition > (i.e. it should have be cut-pasting instead). > - Double inclusion of headers (with missing or broken #ifdef guards). (There is a separate warning flag for broken header guards, -Wheader-guard: https://github.com/ClangBuiltLinux/linux/issues?q=is%3Aissue+label%3A-Wheader-guard+is%3Aclosed) What happens should the kernel move to gnu11, as discussed once GCC 5.1+ becomes the minimum supported version for all arches? https://lore.kernel.org/lkml/CAHk-=whnKkj5CSbj-uG_MVVUsPZ6ppd_MFhZf_kpXDkh2MAVRA@xxxxxxxxxxxxxx/ Then the warning will not fire, since it's only really meant to help C code be portable between -std=c11. (Another change to clang could be to move this flag into the -Wpedantic group, which is only really meant for from guarding against the use of non-ISO C functionality, but that still would require disabling the warning for older but supported versions of clang). > > Those may be providing value in the kernel. In particular, if we don't > see any warning at the moment, it means those cases are not happening > now anywhere, so we would be weakening things. > > Having said that, I don't see the original patch, so perhaps I am > missing something. https://lore.kernel.org/linux-mm/20210215204909.3824509-1-willy@xxxxxxxxxxxxx/ -- Thanks, ~Nick Desaulniers
