lint: merge mod_t.m_test_context into m_requires_bool

These two flags mean exactly the same.

No functional change.

lint: expand abbreviations in definitions of operator properties

No functional change.

lint: move getopname over to tree.c

Except for the one use in print_tnode, the name of the operator is only
used in tree.c.

No functional change.

lint: remove redundant operator properties table

It's enough to have modtab, which describes the properties of the
various operators. There is no need to have a second table imods that
holds the sa

lint: remove redundant operator properties table

It's enough to have modtab, which describes the properties of the
various operators. There is no need to have a second table imods that
holds the same content. Rather make modtab constant as well.

The only possible functional change is that the names of the internal
operators 'no-op', '++', '--', 'real', 'imag' and 'case' may appear in
diagnostics, where previously lint invoked undefined behavior by passing
a null pointer for a '%s' conversion specifier.

show more ...

lint: fix argument names and table headings for operator definitions

The abbreviations in the table of operator properties had been wrong
since ops.def 1.10 from 2021-01-12, when strict bool mode wa

lint: fix argument names and table headings for operator definitions

The abbreviations in the table of operator properties had been wrong
since ops.def 1.10 from 2021-01-12, when strict bool mode was added. In
an earlier working draft, I had named that column 'takes_others' instead
of 'requires_bool', that's where the 'o' came from.

The names of the macro arguments had been wrong since op.h 1.11 from
2021-01-09, when the order of the columns changed and the macros were
not adjusted accordingly. Since all the properties of the operator
table are uniform, this didn't result in any bugs, it was just confusing
for human readers.

Clang-tidy suggests to enclose the macro arguments in oper.c in
parentheses but that is not possible since the arguments are either
empty or 1, and the syntactical ambiguity of the '+ 0' being either a
unary or a binary operator is needed here.

No change to the resulting binary.

show more ...

lint: make lint's own code pass the strict bool mode

No functional change.

lint: clean up code (mostly comments)

lint: replace 0 and 1 with false and true, where appropriate

Change in behavior: Passing the option -h exactly 4294967296 times or
any multiple thereof is no longer equivalent to passing it never at

lint: replace 0 and 1 with false and true, where appropriate

Change in behavior: Passing the option -h exactly 4294967296 times or
any multiple thereof is no longer equivalent to passing it never at all,
it is now equivalent to passing it once. See main2.c, hflag++ for the
actual change.

Other than that, no functional change intended.

A very large portion of the code already conformed to the requirements
of the strict bool mode. The only missing thing was using the constant
literals false and true instead of 0 and 1. For sure there are some
integer literals left that can be converted. For now, all literals that
appeared in the form " = 0" or " = 1" have been replaced.

show more ...

lint: add new check for strict bool mode

In strict bool mode, bool is considered incompatible with all other
scalar types, just as in Java, C#, Pascal.

The controlling expressions in if statements,

lint: add new check for strict bool mode

In strict bool mode, bool is considered incompatible with all other
scalar types, just as in Java, C#, Pascal.

The controlling expressions in if statements, while loops, for loops and
the '?:' operator must be of type bool. The logical operators work on
bool instead of int, the bitwise operators accept both integer and bool.
The arithmetic operators don't accept bool.

Since <stdbool.h> implements bool using C preprocessor macros instead of
predefining the identifiers "true" and "false", the integer constants 0
and 1 may be used in all contexts that require a bool expression.
Except from these, no implicit conversion between bool and scalar types
is allowed.

See usr.bin/tests/xlint/lint1/d_c99_bool_strict.c for more details.

The command line option -T has been chosen because all obvious choices
(-b or -B for bool, -s or -S for strict) are already in use. The -T may
stand for "types are checked strictly".

The default behavior of lint doesn't change. The strict bool check is
purely optional.

An example program for strict bool mode is usr.bin/make, which has been
using explicit comparisons such as p != NULL, ch != '\0' or n > 0 in
most places for a long time now, even before the refactoring in 2020.

show more ...

lint: make the table containing the operator properties more readable

The C preprocessor does not require its arguments to be expressions, an
empty string is valid as well. This allows to replace t

lint: make the table containing the operator properties more readable

The C preprocessor does not require its arguments to be expressions, an
empty string is valid as well. This allows to replace the 0 in the
operator properties table with a space, making the 1 stick out.

Since the table is quite long, divide it into sections and add section
headers.

No change in the generated code.

show more ...

lint: rename ops.c to oper.c

The file ops.c had previously been autogenerated. This meant that in a
NetBSD build, it was generated in OBJDIR, and a build that had just
updated src/usr.bin would fai

lint: rename ops.c to oper.c

The file ops.c had previously been autogenerated. This meant that in a
NetBSD build, it was generated in OBJDIR, and a build that had just
updated src/usr.bin would fail. For a build that last ran on
2020-12-01, and again today, it looks like this:

# link lint1/lint1
cc ... -o lint1 cgram.lo ... ops.lo ... tyname.lo
/usr/bin/ld: ops.lo: in function `initmtab':
ops.c:(.text+0x63): undefined reference to `STRUCT_ASSIGN'

This is caused by ops.c existing in OBJDIR, so the new version in
NETBSDSRCDIR is not looked at. To prevent this, use oper.c instead as
the filename, which has not been used before.

https://mail-index.netbsd.org/source-changes-d/2021/01/09/msg013096.html

show more ...