There is no danger in allowing (flags & FLAG) as a controlling
expression, provided that it is immediately compared to zero, such as in
an if statement or as the operand of a logical operator.
The previous version of lint(1) from a few hours ago didn't catch all
occurrences. And even the current one doesn't catch everything.
Function arguments and return types still need some work. The "return
quietly" from shouldDieQuietly still implicitly converts from int to
_Bool.
No functional change.
- New /etc/security check for entropy in daily security report.
- New /etc/rc.d/entropy script runs (after random_seed and rndctl) to
check for entropy at boot -- in rc.conf, you can:
. set `entropy=check' to halt multiuser boot and enter single-user
mode if not enough entropy
. set `entropy=wait' to make multiuser boot wait until enough entropy
Default is to always boot without waiting -- and rely on other
channels like security report to alert the operator if there's a
problem.
- New man page entropy(7) discussing the higher-level concepts and
system integration with cross-references.
- New paragraph in afterboot(8) about entropy citing entropy(7) for
more details.
This change addresses many of the issues discussed in security/55659.
This is a first draft; happy to take improvements to the man pages and
scripted messages to improve clarity.
I considered changing motd to include an entropy warning with a
reference to the entropy(7) man page, but it's a little trickier:
- Not sure it's appropriate for all users to see at login rather than
users who have power to affect the entropy estimate (maybe it is,
just haven't decided).
- We only have a mechanism for changing once at boot; the message would
remain until next boot even if an operator adds enough entropy.
- The mechanism isn't really conducive to making a message appear
conditionally from boot to boot.
Most of the make code already followed the style of explicitly writing
(ptr != NULL) instead of the shorter (ptr) in conditions.
The remaining 50 instances have been found by an experimental,
unpublished check in lint(1) that treats bool expressions as
incompatible to any other scalar type, just as in Java, C#, Pascal and
several other languages.
The only unsafe operation on Boolean that is left over is (flags &
FLAG), for an enum implementing a bit set. If Boolean is an ordinary
integer type (the default), some high bits may get lost. But if Boolean
is the same as _Bool (by compiling with -DUSE_C99_BOOLEAN), C99 6.3.1.2
defines that a conversion from any scalar to the type _Bool acts as a
comparison to 0, which cannot lose any bits.
This reduces the indentation and allows the messages in the comments to
contain the complete text instead of only an abbreviated prefix.
No functional change.
This strict mode is not yet implemented. The plan is to use it for
usr.bin/make, to get rid of the many possible variants of defining the
Boolean type in make.h. These variants did find some bugs, but not
reliably so. Using static analysis seems more promising for this.
In an early stage of developing this test, lint1 crashed in the enum
definition in line 213, where the node for the '?:' had been NULL. This
can happen in other situations as well, such as with syntax errors, but
these should be rare, as lint is usually only run if the compiler has
accepted the source code. Still, there should not be any assertion
failures while running lint1.
The previous names tspec_is_int and tspec_is_uint were confusing because
there are actually tspec_t constants called INT and UINT, these
classification macros return true for other integer types as well,
though.
While here, remove the prefix "tspec_" from these macros. It wasn't as
helpful as intended, in many cases it was obviously redundant, when it
was called as tspec_is_integer(tn->tn_type->t_tspec).
No functional change.
Contrary to the comment in typeok, the types of the expressions before
promotions and conversions are not needed for SHL, SHLASS and SHRASS.
Move that code over to typeok_shr, the only place where it is actually
used. This removes another 3 variables from typeok.
The code in typeok is already complicated enough. Only few of the
checks actually examine the subtype of the pointer, the others don't
need to look at it. Therefore don't initialize the variables lstp
(left-hand side subtype) and rstp unless they are actually needed.
This reduces the number of variables in typeok and the number of
parameters to the sub-functions.
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.
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
