lint warnings (was: Re: CVS commit: src)

[Roland Illig <roland.illig%gmx.de@localhost>]

27.06.2022 01:20:20 Christos Zoulas <christos%astron.com@localhost>:

> In article <20220624201621.EF2AFFB1B%cvs.NetBSD.org@localhost>,
> Roland Illig <source-changes-d%NetBSD.org@localhost> 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 mean it is ok to teach lint about cases
> like this to reduce noise, but we are changing the behavior from what
> is linguistically acceptable, into what is common practice acceptable
> and I think this should be enabled via a command line switch.

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.

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.

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.

Roland