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.
At the end of a function definition (funcend), curr_pos was not
restored, probably because the very next action is to read the next
token, which will then set curr_pos.
Again, this may affect the location reported in assertion failures,
everything else is unchanged.
This one is already a little trickier since it does not restore the
original curr_pos. This function is only called in a few places, and
these either restore curr_pos themselves or only call functions
afterwards that immediately overwrite curr_pos.
Except for lint_assert, which may now report a different location.
The call to check_global_variable that is related to check_tag_usage was
the function that started this whole refactoring since its lint_assert
reported a completely wrong location when using a compound literal in an
initializer expression at block level 0.
Right now there are several places in the code that use the global
variable curr_pos for passing a parameter to the diagnostic functions.
That's not what global variables are for.
Make it easy for the code to migrate to the parameter-passing style.
No functional change.
A compound literal that occurs at block_level 0 does not have storage
class AUTO. Instead, its storage class is either EXTERN or STATIC.
While removing the temporary objects from the symbol table had prevented
the assertion, it did not properly fix the underlying problem, which was
that since C99 the initializers can contain references to unnamed
objects that are created on-the-fly. For C90 it was correct to always
use AUTO as the storage class of a temporary symbol.
you can have races when multiple processes try to unlink it. Check the link
count to see if we have won the race.
While here:
- use snprintf
- use warn
- use size_t/ssize_t
- use loops instead of goto
- KNF
The word 'write' now means to write to the file that holds the shell
commands to be run later.
The word 'print' is now used exclusively for handling the output of the
child commands and printing them to make's stdout.
No functional change.
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.
No special handling is necessary for C90 since none of the struct
members is a const_member.
The prefix 'Var' is not necessary since this type does not apply to a
variable but only to a modifier.
No functional change.
mDNSResponder: another wrong return local address
dhcp: ignore a seemingly impossible stringop overflow
hpacel: avoid maybe uninitialised error that is wrong.
rsh: avoid impossible malloc(0)
udf: cast pointers through (uintptr_t) to fool invalid boundary checks
Previously, SysVMatch was quite verbose and felt like hand-optimized
assembler code, which made it difficult to discover the underlying idea
of the code.
All this code was replaced with two simple calls to Substring_HasPrefix
and Substring_HasSuffix. Now that the operands of that modifier are no
longer passed as C strings, there is no need to collect all information
in a single scan through the word and the pattern.
It was not necessary to call Var_Subst unconditionally. Calling it only
when the string contains a '$' saves another memory allocation and two
string copies (because of the Buf_DoneDataCompact).
No functional change.
I had forgotten to remove the single quotes, to produce a really empty
word. Plus I had forgotten the modifier ':Q' for the result, which
meant that the single quotes did not show up in the output.
The previous O(n^2) time complexity for parsing a long string with many
variable expressions was not meant to last for long. I had hoped to fix
it within a few minutes, but that will take more time.
For now, make LazyBuf simpler by using a traditional C string for the
expected part instead of a Substring. This avoids a strlen call per
Var_Parse.
No functional change, only performance.
This benefits the modifiers ':T' and ':H' since these scan the word from
the end. The SysV modifier '.c=.o' does not benefit yet, this will be
done in a follow-up commit.
Currently ModifyWords calls strlen for each single word, which degrades
performance. This will be cleaned up in a follow-up commit as well.
No functional change.
Right now this does not gain any performance, it only makes the code in
ModifyWord_Subst a little simpler since it only uses
Buf_AddBytesBetween, not a mixture with Buf_AddBytes.
When the word passed to the ModifyWord functions is converted to
Substring as well, the call to strlen will become redundant.
No functional change.
The main change is in ParseVarname, where a Buffer is replaced with the
newly introduced LazyBuf. LazyBuf is inspired by
https://golang.org/src/path/path.go.
In CanonicalVarname, the pre-comparison of the first letter of the
variable name is no longer necessary. GCC 9 optimizes a fixed-length
memcmp so well that the code can finally be written to target human
readers, leaving the optimization to the compiler.
These will be used for making the string handling more efficient,
avoiding allocations, especially when evaluating variable expressions.
Since the string handling has grown quite a bit in the last months,
extract it into its own header file.
No functional change.
Expressions of the form ${:U...} are often generated by .for loops.
Since these expressions are not generated knowingly by the make user, do
not fill the debug log with them since that would interrupt the normal
reading flow of the -dv log for nested expressions.
Expressions of the form ${:U...} are often generated by .for loops.
Since these expressions are not generated knowingly by the make user, do
not fill the debug log with them since that would interrupt the normal
reading flow of the -dv log for nested expressions.
Having two similar but still different definitions of 'struct type' is
unnecessarily confusing. Exchange this confusion for 8 lines of
straight-forward preprocessing code.
It's confusing to have the same struct tag in both lint1 and lint2, with
mostly the same members, but also some differences. Before actually
changing this, I reviewed all occurrences of the word 'type' in the
code.
No functional change.
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.
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.
