The length/scale example at the beginning is not all literal.
Fix remaining "quoted" words to use .Dq
Fix a few small inline code snippets to be literal.
- 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
Reduce memory footprint and processing time by dropping the vertex parts
of the edges kept during the peeling. Hook up the
division-by-multiplication logic to help older platforms.
i386 is an ILP32 platform (arch/i386/targparam.h). On these platforms,
int and long have the same size, and even with the -p option for
portability checks, INT_RSIZE in inittyp.c is defined to 4, not 3.
Because of this, in check_integer_conversion, psize(nt) was not greater
than psize(ot), and the warning was not issued.
To make the test behave the same on all platforms, changed the long
variables to long long, since long long is 64-bit on all platforms, and
int is 32-bit.
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.
This warning is the only one that calls print_tnode, which in turn uses
the redundant operator names in str_op_t.
There is another list of operator names in ops.c, but those names
include more clutter, for example "p + p" instead of a simple "+".
Using those operator names would therefore rather be confusing. These
two lists should be merged, to remove unnecessary redundancy.
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.
