Previously, declaring a bit-field of type plain 'int' resulted in this
warning:
warning: nonportable bit-field type 'int' [34]
This warning was too unspecific to be actionable, and until yesterday it
didn't even include the type. In order to allow this warning to be
understood and properly fixed, describe the actual nonportability more
precisely:
warning: bit-field of type plain 'int' has
implementation-defined signedness [344]
The test cases are the same as in opt-debug-errors.mk. The output
differs in several details though.
Even though the option '-k' is given (which is the default for any tests
that don't override it in unit-tests/Makefile), there is no message
"(continuing)" anywhere.
The failed target is printed twice. Once before the failed commands,
once after. This redundancy is not necessary and may be removed in a
follow-up commit.
The printed commands are in their unexpanded form, which may or may not
be more helpful than the expanded and space-normalized form of compat
mode. Either way, this is an unnecessary inconsistency between compat
mode and jobs mode.
In jobs mode, the message "make: stopped in $dir" is printed for each
failure, which is helpful since each of the jobs may have started in a
separate directory.
Pointed out by Anders Gustafsson on port-hp300@.
https://mail-index.netbsd.org/port-hp300/2021/04/21/msg000201.html
Should be pulled up to netbsd-8 and netbsd-9.
XXX: kernel should use the dhcpd/bootp server address for nfsroot
if the specified next-server (siaddr) is 0.0.0.0?
Even though the new test is quite large, it didn't find any bugs in the
code. The only thing I'm unsure about is why static functions are
exported as well, since they are supposed to be local to the translation
unit.
Previously, the standard NetBSD build generated several lint warnings in
lhash.h from OpenSSL, without providing any hint as to which file
actually included that header. In cases like these, lint now interprets
the line number information in the preprocessor output from GCC to
reconstruct the exact include path to the file in question.
The program check-expect.lua had to be rewritten almost completely since
it assumed that all diagnostics would come from the main file. In all
existing tests, this was true, but these tests did not cover all cases
that occurred in practice. Now it records the complete location of the
diagnostic instead of just the line number.
The argument to most of the functions from <ctype.h> "shall either be
representable as an 'unsigned char' or shall equal the value of the
macro EOF".
When confronted with the infamous warning 'array subscript has type
char', there are enough programmers who don't know the background of
that warning and thus fix it in a wrong way. Neither GCC nor Clang
explain its warning to target these programmers.
Both GCC and Clang warn about 'array subscript has type char', but they
ignore the other requirements of the <ctype.h> functions, even though
these are in the C standard library.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94182https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95177https://stackoverflow.com/a/60696378
The file varmod-loop.mk has grown too large to be single-purpose, plus
it combined parse-time and run-time tests. This has the downside that
as soon as a parse-time test results in an error, the run-time tests are
not run anymore.
The following code is valid:
int valid = {{{ 3 }}};
C90 3.5.7 and C99 6.7.8 both say that the "initializer for a scalar
shall be a single expression, optionally enclosed in braces". They
don't put any upper bound on the amount of braces, not even in the
"Translation limits" section.
outgrown the previous size specification when the system was built
with all of MKDEBUG, MKKDEBUG, and MKDEBUGLIB set to "yes" (and
also when in-tree X11 is included).
So, bump the size a bit.
The errors in line 74 and 75 of the test are wrong. Everything is fine
there. The bug lies in init_array_using_string, try to see if you can
spot it, neither GCC 9.3.0 nor Clang 8.0.1 could.
The basic idea of indent is to split the input into tokens and then
reassemble them, reformatting them on the way. These tokens determine
how the output is formatted, therefore add tests for each of the
terminal tokens and nonterminal parser symbols, to cover more common
cases, and edge cases as well.
Given that indent "has even more switches than ls(1)", there are far too
few tests. To make it easier to add meaningful tests for each of the
options, add the templates for the tests right now, ready to be filled
in.
indent cannot handle line-end comments.
The indent test suite requires each test file to have both a NetBSD and
a FreeBSD RCS ID. If the FreeBSD RCS ID is missing, the test will
silently pass since in that case, an empty file is compared with an
empty file. See the /start/,/end/ operator in t_indent.sh.
Add a sh ATF test to demonstrate a bug in the way that \0 characters
are dropped from scripts. This test will eventually be extended to
test other potential sh script input related issues.
When initially committed, this test should fail. It should succeed
when the fix for the PR is committed (soon).
Nb: this tests only the \0 related issues from the PR, the MSAN
detected uninitialised variable (struct field) can only be detected
by MSAN, as it has no visible impact on the operation of the shell
when running on any real (or even emulated) hardware.
(It will, however, also be fixed).
In lists/base/mi, the directory ./libdata/firmware contains several
subdirectories for which the entries do not look aligned right now, even
after normalizing the alignment.
This is because the indentation for a directory is not determined
globally for all directory entries from the complete file, but instead
for each group of items, after sorting, that have the same directory.
This results in several entries having only a single item per group,
such as ./libdata/firmware/nouveau, and this single item is obviously
consistently indented since all of its 1 lines are already indented to
the same depth.
One possible solution for this is to sort the entries in another order,
keeping all entries from a directory together. This allows to quickly
see all entries from a certain directory, but on the other hand, when
adding a new directory plus some entries, the directory has to be listed
far away from its entries. (This would be done automatically by
fmt-list though, which weakens this argument a bit.)
Another possible solution for this is to first determine the indentation
for all entries from each directory, no matter how far these entries are
apart, and then indent these entries to the common indentation. This
may or may not help since there will still be single entries between
groups of differently indented entries.
Writing down the intuitive rules for how to align the entries properly
is a nontrivial task. See pkglint/varalignblock, which is around 650
lines of code, plus around 4000 lines of test code.
No functional change.
Seen in lists/modules/ad.aarch64, among others. These lines are not
intended as comments but as regular entries that just happen to be
commented out.
This is the same as how pkglint treats commented variable assignments,
which take part in aligning blocks of variable assignments even though
they are syntactically comments.
When adding "\t" via addch, win.curx advances by twice the spaces as
intended. This bug was introduced somewhere between NetBSD 8.0 and 9.0.
Adding "\t" via addstr does not have this bug.
This bug causes the installation menu of sysinst to be have its menu
items indented by 16 characters instead of only 8. This in turn
produces an ugly line break in the German translation.
The test framework for libcurses is not well integrated into ATF.
Whenever the expected output is longer than the actual output, or vice
versa, the test passes nevertheless. This makes it necessary to
constantly look into atf-run.log to see whether the actual output is
indeed equal to the expected output, which is crucial, especially for
telling the difference between addstr and addnstr.
Reusing the .chk files for several tests is not a good idea either. For
example, addstr and waddstr are supposed to produce the same result for
ASCII-only text, so it was tempting to use the same file. But waddstr
seems to have a bug (maybe undefined behavior), at least waddstr returns
ERR in one case where it shouldn't. This means that currently the
expected output (acknowledging the bug) must be different.
The "expected" test output in waddstr.chk looks completely broken, but
that's exactly what the test produces right now.
temporary use where allocation on the stack is desirable, but only up to
a certain size. If the requested size fits within the specified stack
buffer, the stack buffer is returned. Otherwise, memory is allocated with
kmem_alloc(). Add a corresponding kmem_tmpbuf_free() function that frees
the memory using kmem_free() if it is not the tempory stack buffer location.
Previously, lint1 allowed integer constants such as 0 and 1 to be used
as bool constants. This was only half-baked since after fixing all
error messages from that strict mode, there may still be integer
literals in the code that should be replaced with true or false. This
would stop a migration from int to bool in the middle, leaving
inconsistent code around.
To find the remaining type inconsistencies, treat integers and bool as
completely incompatible, even for compile time constants.
MKDEBUG are defined, we create an empty $DESTDIR/usr/libdata/debug/netbsd/
directory.
Should fix ``build.sh release'' issue reported in kern/55923
XXX Since nothing ever seems to populate this directory, perhaps we should
XXX simply prevent its creation? If we do create it, should its creation
XXX perhaps be conditioned on MKKDEBUG rather than MKDEBUG?
XXX There is still another problem with ``build.sh install-image'' but I
XXX open a new PR for that.
- 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.
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.
Having a test for each message ensures that upcoming refactorings don't
break the basic functionality. Adding the tests will also discover
previously unknown bugs in lint.
The tests ensure that every lint message can actually be triggered, and
they demonstrate how to do so. Having a separate file for each test
leaves enough space for documenting historical anecdotes, rationale or
edge cases, keeping them away from the source code.
The interesting details of this commit are in Makefile and
t_integration.sh. All other files are just auto-generated.
When running the tests as part of ATF, they are packed together as a
single test case. Conceptually, it would have been better to have each
test as a separate test case, but ATF quickly becomes very slow as soon
as a test program defines too many test cases, and 50 is already too
many. The time complexity is O(n^2), not O(n) as one would expect.
It's the same problem as in tests/usr.bin/make, which has over 300 test
cases as well.
meson-g12b-odroid-n2-plus.dts of linux is not optimized for the odroid-N2plus CPU clock.
and the dts for odroid-n2-plus in the hardkernel repository is significantly changed,
so cannot be imported without modification. Therefore, a simple meson-g12b-odroid-n2-plus.dts
has been added based on "meson-g12b-odroid-n2.dts" with only the cpu_opp_table and
regulator table changed.
Exporting the variables at the right time and with the correct values is
a subtle issue. The current implementation carefully marks variables as
ready to be exported, then exports them and at the same time tries to
export as few variables as possible, to avoid memory leaks. This test
describes and explains how all this works in detail.
This test also justifies that the call to Var_ReexportVars happens in
the make process itself, not in the child processes, no matter whether
these are created with vfork or (only theoretically) with plain fork.
This has changed in compat.c 1.217, job.c 1.390 and main.c 1.504 from
2020-12-27.
martin