tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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

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 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


Home | Main Index | Thread Index | Old Index