The functions 'debug_node' and 'display_expression' were similar enough
to be merged.
Migrate debug_node to use the existing debug logging functions.
Remove the now unused option 'd' from the options string.
The command line option -d was not used by /usr/bin/lint, and it only
triggered a handful of debug messages. Move this debug logging over to
the compile-time -DDEBUG setting.
Move display_expression further up to avoid the forward declaration.
Conceptually, a symbol buffer does not need to remember its hash value
since that belongs to the symbol table. This makes the code for the
symbol table simpler. The number of hash calculations increases by
about 5%, which is negligible.
No functional change.
When I tried to fix msg_115, I quickly ran into a segmentation fault,
probably related to the symbol table. To better understand this part,
log insertions and deletions.
The other debug log messages do not need to mention the current file
position anymore, this is what lex_next_line takes care of since scan.l
1.113 from 2021-01-05.
For the .ln files, I chose the letter 'J' to represent the 128-bit
integer types since it is close to 'I' for int. The naming of 'L' for
'long' is obvious, but 'Q' for 64-bit integers is a quad-16-bit word,
which is an unusual measurement unit nowadays. One benefit of choosing
'J' is that the next letter, 'K' can then be used for 256-bit integer
types.
Support for 128-bit integer types is still very basic. Plus, it is only
supported on LP64 platforms, which means that lint cannot be
cross-compiled to check for an LP64 platform while running on an ILP32
platform.
To analyze the unexpected test failure of op_shl_lp64, I had reverted
debug_step to evaluate its arguments. I then accidentally committed
that without running the tests again.
Anyway, the previous commit can now be used as a demonstration that
initdecl is indeed missing the initialization for __uint128_t, which
leads to the internal error in op_shl_lp64.
The calls to debug_step, unlike printf, don't need a trailing newline.
Remove the debug_step0 macro and its relatives since lint already uses
enough other features from C99 that it essentially requires this
standard, which supports varargs macro arguments. Among these features
are __func__ and printf("%zu").
In non-debug mode, do not evaluate the arguments of debug_step.
Evaluating the arguments had caused an internal error when running the
test op_shl_lp64. This is indeed a bug since initdecl should have
initialized the type table for __uint128_t. This had been forgotten
when support for __uint128_t was added in decl.c 1.69 from 2018-09-07.
No functional change.
Lint currently has several different kinds of debug log:
* The -DDEBUG log is controlled at compile time.
* The -d command line options enables some other debug logging.
* The -DYYDEBUG log for parsing is controlled at compile time.
* The -y command line option only has an effect in -DYYDEBUG mode.
Extracting the logging into a separate file is a first step towards
unifying these logs and making the code for debug logging stand out less
than the current #ifdef DEBUG.
No functional change.
The code 't_const = false' occurs 4 times in the lint code, each
corresponding to one of the wrong warnings in the test.
This bug has been existing at least since 2001. Back then, the lint
output was:
2001.12.24.20.52.09
| (23): lint error: popctrl() 1
| (15): syntax error [249]
| (19): warning: left operand of 'FARG' must be modifiable lvalue [115]
| (21): syntax error [249]
| (23): warning: function initialize_const_struct_member falls off bottom without returning value [217]
| exit status 1
from 2002.12.06.03.27.39
| (23): lint error: func.c, 168: popctrl()
| (15): warning: left operand of '=' must be modifiable lvalue [115]
| (19): warning: left operand of 'FARG' must be modifiable lvalue [115]
| (21): syntax error [249]
| (23): warning: function initialize_const_struct_member falls off bottom without returning value [217]
| exit status 1
until 2003.10.27.00.12.44
The string functions from str.h are declared as 'static __unused' when
compiled with GCC, but lint explicitly undefines __GCC__ during
preprocessing. Therefore, make those functions inline, to prevent
warnings that they are unused.
The macro UNCONST is used in a few places, and (again) since lint
undefines __GCC__, that macro expanded to a simple type cast, which lint
warned about. To prevent this warning, implement UNCONST as a function
that works everywhere and hides the type cast.
In filemon_open, the code for closing F->in was obviously unreachable.
No functional change.
oster