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.
