Re: usefulness of lint (was: Re: Proposal: remove usr.bin/mkstr)

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

Am 10.04.2022 um 00:15 schrieb David Holland:
> On Sat, Apr 09, 2022 at 03:16:24PM +0200, Roland Illig wrote:
>   > > That's just like lint - once used all the time, code was not accepted
>   > > if not lint free, now essentially useless as tge compilers have most
>   > > of its functionality built in.   If being old and no longer very useful
>   > > is the test, then lint should go too.  Perhaps so should I.
>   >
>   > Do you know of any C compiler that [...]
>
> We should not remove lint until we have another program checker to
> replace it with, but it is not itself very useful. And yes, I know
> you've been working on it and I haven't been following the details,
> but it will take far more than the time you've put in (and a ground-up
> restructuring) to become even as useful as lclint or sparse, let alone
> comparable to a state-of-the-art program checker.

Could you go into the details of what you mean by "ground-up"? The basic
concepts and data types (expression, type, symbol, operator) look
sensible to me. Sure, the memory management is hard to understand at
first, I'm preparing a README file for that.

Here's a broad summary of what I changed in lint:

I started working on lint when it couldn't parse a simple C99-style
initialization. That works now.

I added "strict bool mode", in which bool is not an arithmetic type
anymore, making any implicit conversion between arithmetic types and
bool illegal. This mode helps in migrating a program from the
traditional 'int flag' to the more restricted 'bool flag', which
expresses the actual intention of the code in a clearer way. Adding this
mode was quite simple, which made me trust the codebase enough to
continue working on it.

I added a check for the functions from <ctype.h> since GCC's diagnostic
about "array subscript has type char" is far away from anything actionable.

I added a check for getopt consistency (see msg_338.c and msg_339.c).

I improved the existing messages by adding more details, such as the
involved types, making them more self-contained, especially in the
presence of deeply nested macros. Oh, and stack traces when the error is
in a deeply nested included file.

For implementation details, I unabbreviated most of the function names
since they contained unnecessary contractions and abbreviations. I fixed
the C grammar to allow for more constructs from C99 and later, thereby
improving the framework to add future custom checks. While there, I
fixed several bugs, I cannot remember them all. If you are interested in
details, search for "from 20" in tests/usr.bin/xlint. Due to the many
new tests I wrote, adding new features or fixing bugs greatly reduces
the danger of accidentally introducing new bugs.

All in all, I mostly trust the code to work well and I think it provides
a solid base.

>   > Do you know of any C compiler that catches the implicit unconst cast in
>   > strstr("literal", "lit")[0] = 'X'?
>
> It used to be that lint did not do this in a useful way (via
> quantifier polymorphism) -- have you improved it?

Yes, but not in a general way. I just listed the few affected functions
explicitly. See
https://nxr.netbsd.org/search?q=%22effectively+discards%22 for the
implementation, the test msg_346.c contains a few examples.

> I tried to check but running lint on a test file spews fatal errors
> trying to read the system headers. If one adds -Ac11 and
> -D'__attribute__(x)=' to avoid these, it does not complain about your
> example, let alone any other more complex ones.

Oh, I can see how lint's default settings result in a bad first-time
experience. Ideally, lint should just work out of the box, without even
having to read the manual. The minimal lint flags to make it usable are
currently -g for GCC mode and -S for C99 mode. That's what I use in the
unit tests as well. I'll try to improve the default settings to be more
user-friendly.

Roland