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.
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.
nakayama