The build failed with this error message:
x86_64--netbsd-install: the last argument (/.../emit.ln) must
name an existing directory
The cause for this message was that ${DESTDIR}/.../emit.ln has
${DESTDIR}/.../emit.c as implicit target, which is kind of correct but
unintended in this case. Because of this, the command 'install' was run
like this:
install ${NETBSDSRCDIR}/.../emit.ln ${DESTDIR}/.../emit.c \
${DESTDIR}/.../emit.ln
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.
The description of the tests is not going to be added anytime soon, as
that would either create redundancy or additional run-time cost.
Parsing and evaluating unit-tests/Makefile is already O(n^2) with regard
to the number of tests, and there are quite a few tests. Therefore don't
add any overhead for now.
The list of available letters for the command line options gets shorter
and shorter. Most of the interesting letters are already used for some
warning categories. Curiously, -A, -W and -E were all still available.
The option -A nicely matches the intention of the option, which is to
allow a certain set of language features. To keep the option available
for further extensions, define -Ac11 as the currently only valid option
of that kind. This allows straight-forward extension for C17 and future
language standards, as well as independent feature-sets. The options -W
and -E may someday complement the -A option, using the allow/warn/error
categories.
bugs that exist in the current code and leave the target machine in
a broken state, requiring ddb or hard reset.
setting ATF_USR_SBIN_CPUCTL_OFFLINE_ENABLE to any non-empty string
will enable these tests again.
C99 allows this form in 6.7.8p14 and p15.
The previous lint tests did not cover the case of an array at the top
level of the object to be initialized, they only covered the error cases
(d_c99_init.c, variables 'prefixed_message' and 'message_with_suffix').
Lint is now more generous than strictly required by C99, but since GCC
and Clang already cover the case of 'message_with_suffix', this is ok.
The test d_init_array_using_string.c was wrong before in rejecting the
initializer for 'extra_braces'. I had tested that Clang generated a
warning for this, but I had not inspected its warning carefully enough.
Clang had not warned about the extra braces but only about a type
mismatch since I tested on a platform where wchar_t was 16 bit.
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.
In a typical NetBSD build, there are about 100,000 lint warnings. About
50,000 of them are warning 247. About 38,000 of these are from OpenSSL
and may be fixed by now.
C99 is too far away from traditional C to make this warning useful.
There are 3 different situations in which this warning is generated:
For '1 << (unsigned char)1', the result type is 'unsigned int' in
traditional C. The result type is unsigned because at least 1 of the
operators is unsigned, and it is 'unsigned int' because the usual
arithmetic promotions are applied.
For '1 >> (long)1', as well as for '1 << (long)1', the result type is
'long' in traditional C since the usual arithmetic promotions are
applied.
Omitting this warning in C99 mode reduces the amount of lint warnings in
a typical NetBSD release build by approximately 6800 of 107000 total.
The previous message 'shift greater than size of object' was too short
to give reasonable hints, especially when the expressions involve
typedefs or macros.
