- add fudge mode which gives a slightly slower hash function, but works
almost always in the first iteration by avoiding degenerate edges
- avoid keeping incidence lists around reducing the memory foot print by
30%
- split edge processing from hashing as in the non-fudge case it is a
reasonable costly part that often gets thrown away
- merge graph2 and graph3 routines now that they are mostly the same
Refactor to not rely upon restartable signals (SA_RESTART),
possibly fixing intermittent failures with -q QUITTIME.
ftp transfers: handle EINTR/EAGAIN in copy_bytes(),
instead of relying upon restartable signals.
http/https transfers: Explicitly print an error similar to
progressmeter() when timing-out for -Q QUITTIME in fetch_wait(),
and set errno to ETIMEDOUT so that the warn() in fetch_url()
prints a more accurate error message.
PR/55857
Instead of running a shell program that runs an AWK program that
generates the two files ops.c and ops.h, just define the operator tables
once in ops.def and use these definitions flexibly in ops.c and op.h.
These symbolic names for INCBEF, INCAFT, DECBEF and DECAFT were
non-standard and thus confusing. All other operators were as expected.
Now that the operator names from ops.def are very similar, there is no
need to keep to almost identical lists around.
No change to the user-visible messages since the only place where these
operator names were used was in 324, and that message was restricted to
PLUS, MINUS, MULT and SHL.
Including the "p" in the symbolic operator names was questionable, for
several reasons:
1. The "p" could be taken to mean an actual variable name, which is
confusing if the function doesn't have such a variable, or even more
so if the line contains an unrelated variable called "p".
2. For the binary operators, having the "p" mentioned on both sides of
the operator (such as in "p + p") wrongly suggested that both
operands of the expression were the same.
3. The name "p" often stands for a pointer. Most of the operators
don't accept pointers, therefore the name was misleading.
For these reasons, the "p" was removed from the symbolic name of all
operators. This makes several pairs of operators indistinguishable:
INCBEF == INCAFT
DECBEF == DECAFT
UPLUS == PLUS
UMINUS == MINUS
STAR == MULT
AMPER == AND
This is not expected to create any confusion since C programmers are
expected to know these double meanings.
The symbolic names for SHLASS and SHRASS were missing the '=' before.
This was added since omitting it was probably an oversight.
In C, only binary operators have possibly confusing precedence. All
binary operators have lower precedence than an explicit cast. When an
expression is parsed, the parentheses are associated with the innermost
possible node. This means that as soon as a cast operator is
parenthesized, its contained expression can no longer have confusing
precedence.
This allows the code to be written more succinct since the local
variables are no longer necessary.
This helps to quickly see where in the source file the parser currently
is. Previously, the parsing position was only printed after each
declaration, as part of "clear flags".
It's difficult to keep these lists in sync when they are spread over
several files. The lists had been inconsistent since 2008-04-26. The
inconsistency didn't lead to undefined behavior though since the
operator names are only used in 2 places:
1. check_integer_conversion in message 324 only calls that function with
a few selected operators, all of which are above the missing ones.
2. mkinit prints the node including its operator, but only in debug
mode. Furthermore I'm not sure whether any of the broken operator names
could ever be accessed at this place since mkinit is only called for
expressions, and the node types are INIT, CASE, FARG, which are all
special.
The function check_precedence_confusion was pretty long, and right in
the middle of that function was the complicated part of determining
which of the operand combinations are confusing and which aren't.
Extract this part into a separate function to document on which
information this decision is based. This makes it easier to understand
the code since there are fewer local variables around.
As a left-over from a previous commit, rop and rparn don't need to be
initialized twice, now that the assertion for a binary operator is in
place.
Remove the large and useless switch statement over all operator types.
This list was completely unsorted, for no apparent reason. To see the
list of operators, better look them up in ops.def, there was no need to
have this list duplicated here.
No functional change.
The operator table in ops.def states that every operator that has
possibly confusing precedence is also a binary operator, so assert that
instead of having two different code paths.
It took quite a while to get to the correct interpretation of this small
piece of code and to draw the right conclusions from it. Now the bug is
finally ready to be fixed, as already announced in the test.
This reduces the visual clutter. There is no reason for anyone to
modify the code around the CALL operator, therefore the assertion is not
expected to fail anytime soon.
The node was dereferenced before the null check. GCC 5.5 didn't warn
about this obvious bug, not even with -Wall -Wextra -O2. Such a case
didn't occur though in the few tests that this function was used in.
The indentation for the nested nodes only needs to be set for a few
lines of code, make this region as small as possible.
There are nodes that use both tn_left and tn_right, even though they are
not defined as binary operators. An example is CALL, for which tn_left
is the address of the function name and tn_right, which are the
arguments, linked via PUSH nodes. CALL is not a binary operator since
it doesn't do any calculations with its arguments.
It now resides right below dumpnode, which implements the same idea but
uses a fixed-size output buffer and prints everything in a single line,
which quickly gets hard to read. Maybe that's the reason why it had
been commented out since it got added in 2014.
From the code alone, it is too difficult to see how the various internal
operators are combined and what properties they have. A simple tree
visualization helps to see all the details.
This is used to track down the typo in check_precedence_confusion, to
see whether it could have possibly had any influence at all.
Anonymous structs and unions have been introduced in C11. The code of
make is supposed to be compatible with C90 though.
The additional members were intended to be used during an interactive
debugging session only and were thus not relevant to running the actual
code.
From the previous short names, it was no obvious that these functions
create a new tree node.
The function named funccall in lint2 has been left as-is, since it has a
completely different prototype.
Most of the code that deals with control statements is only interested
in the innermost control statement, and not if that is a stack or not.
Therefore, emphasize that part in the variable name.
The member c_next was confusing since the "direction" of this "next
element" was ambiguous. In a sequence of if statements, the "next"
element could have equally been the following one, not the surrounding
one.
It's shorter, and the other flags of the type or declaration also don't
have "is" in their names. Except for t_isenum, but that's because there
is a macro named t_enum that would interfere with that name.
Since several years GCC validates printf-style strings, and there is no
reason not to let GCC do that work. This prevents bugs like the
segmentation fault that was fixed in tree.c 1.109 from 2021-01-01.
By default, lint is compiled with DEBUG off, but it's easy enough to
compile it in debug mode once in a while.
The return value was only used in a single case. Duplicating the
condition for printing a message is ok in that case, since it makes all
other places in the code simpler.
The occasional "(void)" or "msg = " before the function call had hidden
the calls from check-msgs.lua, which didn't check the message texts in
such cases.
Even though this results in more lines of code, the benefit is that the
message text in the comment is verified by check-msgs.lua. The code is
also easier to read, the parentheses and asterisk were not needed.
