In article <68ea25e4-a22b-4fbc-af8c-30c4195d2...@gmx.de>, Roland Illig <roland.il...@gmx.de> wrote: >27.06.2022 01:20:20 Christos Zoulas <chris...@astron.com>: > >> In article <20220624201621.ef2aff...@cvs.netbsd.org>, >> Roland Illig <source-changes-d@NetBSD.org> wrote: >>> -=-=-=-=-=- >>> >>> Module Name:Â Â Â src >>> Committed By:Â Â rillig >>> Date:Â Â Â Â Â Â Fri Jun 24 20:16:21 UTC 2022 >>> >>> Modified Files: >>> Â Â Â src/tests/usr.bin/xlint/lint1: msg_247.c >>> Â Â Â src/usr.bin/xlint/lint1: tree.c >>> >>> Log Message: >>> lint: do not warn about pointer cast between sockaddr variants >> >> Doesn't gcc warn for this? > >No, it doesn't. As we compile most of our code with -Werror, we would >have noticed that.
I think that I've seen some pointer aliasing warning, but I could be wrong. >I don't want to add any new command line switches to lint for specific >cases like these, as we will quickly run out of letters. Instead, I'd >rather define a "profile" named "NetBSD-userland" or "NetBSD-external" >or "NetBSD-kernel". In these profiles, optional warnings could be >switched using descriptive names, in addition to specific message IDs. >These profiles would also allow to turn specific warnings into errors. That is fine. >My expectation of lint is that it warns me about possible bugs, and >casting between the sockaddr variants is required by the API, therefore >I don't see a point in flagging it as a possible bug. > >Or would you rather fix all the current warnings by adding an >intermediate cast to 'void *'? That would be a lot of work, plus the >intermediate cast can hide other typos. There is no intermediate cast needed; you can just cast the sockaddr flavor to (void *) or (const void *). >Similarly for the cast from 'pointer to array[20] of double' to 'pointer >to double': I don't see how that could be dangerous, therefore I >switched off this warning unconditionally. Lint now misses casts between >pointers to arrays of the same base type but different lengths, but >pointers to arrays are rare enough that I simply ignored this case. In >practice, these cases typically wrap the array in a struct. > >The state from 4 days ago where we had 12000 warnings of this kind >alone, most of which were noise, was not acceptable to me, as nobody can >be expected to walk through this amount of warnings, repeatedly checking >for false positives just to find the 5% of the warnings that might be >interesting. Yes, and I was thinking to wrap them all up into a pedantic flag instead. christos
