"PR/54435: Adjust for new kernel behavior of soreceive(9) clearing MSG_OOB"
That change was trying to make rlogin work again after the SIOCATMARK ioctl
was broken, but that kernel bug has now been fixed, so the original rlogin code
now works again. Further, the changed rlogin code actually did the wrong thing,
by treating reception of the MSG_OOB byte as meaning that we are now
"at the mark", but that is not true... we are "at the mark" only when
we have reached the point in the stream where the MSG_OOB byte was originally,
as indicated by SIOCATMARK. So going back to the previous code seems best
all around. ok'd by christos.
In 'sametype', the branch for comparing array types was unreachable
since it requires both tspecs to be the same, but t2 underwent the
array-to-pointer conversion.
Previously, lint warned about enum type mismatches, even without -e for
strict enum mode. Instead, it got the case for 'char *' wrong, which is
now fixed. Now lint behaves like GCC 10.3.0 in this regard. The
warning about enum mismatch is useful though, so it may be re-added in a
future commit.
This function is only used by lint1. That's good since the lint2 code
was completely broken, as it would regard any two struct types as being
the same.
Remove the large switch statement since it is unlikely that there will
be new type derivations in C anytime soon.
No functional change.
The variable modifier ':On' sorts words numerically. If these words are
not numeric at all, they get assigned the numeric value 0. Internally,
':On' uses qsort for sorting the words. Since qsort is not specified to
use a stable sorting algorithm, the test data must only use words that
either are written in the same way or that are numerically different.
The test varmod-order failed this requirement by trying to numerically
sort a list of non-numeric words. This led to different results on BSD
and Ubuntu, as could be expected.
To fix the tests, distinguish between words and numbers in the tests.
While here, clean up the tests for all variants of the variable modifier
':O'.
Found by sjg on Ubuntu.
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 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.
Previously, the error handling for the variable modifier ':O' differed
depending on the exact variant and in some cases led to misleading
or missing diagnostics.
Just to see whether it is possible to write a conditional in the form
${ ${A} < ${B} :? ${A} : ${B} }, that is, with leading and trailing
whitespace, to make it easier for humans to read the code.
It's not possible, the result of this computation cannot be used in
further numeric comparisons, at least not in .if directives. Leading
space would work, but trailing space wouldn't.
On the other hand, they would work in expressions of the form
${ ${A} < ${B} :? ... : ... } since in these, the condition is first
expanded and then parsed. But that is an implementation detail that is
not documented and it is also difficult to understand.
The grammar rule for assignment_expression is quite different from those
of the other expressions, for 2 reasons: first, its precedence is
right-to-left. Second, its left-hand side must be an lvalue, which
rules out all binary operators. K&R C even had a grammar rule named
'lvalue' for this purpose. Later C standards made the kinds of
expressions more fine-grained and used 'unary_expression' in this place.
chs