In the early phase of lexical analysis, the '*' does not mean
multiplication, therefore its name should not suggest that. It is only
an asterisk, and depending on the surrounding context, it will only
later turn into a pointer dereference or a multiplication.
The call operator(T_MULT, MULT) was misleading since the MULT was not
used at all.
We may still suppress the rest of the noise if shouldDieQuietly
says to, but the 'stopped in' output is too important to lose.
Avoid repeating it though in the same process.
For the case of aborting due to failure detected elsewhere,
exit 6 so we have a clue.
PR: 55578
Reviewed by:
It's perfectly valid to directly use a function name as the controlling
expression of an if statement. That function name is converted
implicitly to a pointer to that function, and that is a scalar value
then.
Spotted by christos in lib/libpthread/pthread.c:634.
In func.c 1.39 from 2020-12-31 18:51:28, the check that controlling
expressions are indeed scalar was extended from while and for loops to
if statements as well. It just seemed to have been an oversight.
This revealed a bug in lint, which didn't accept the following valid
code snippet from lib/libpthread/pthread.c:634:
void _malloc_thread_cleanup(void) __weak;
...
if (_malloc_thread_cleanup)
_malloc_thread_cleanup();
Testing a function (instead of a function pointer) for truthiness is
probably rare since most functions are defined unconditionally. For
weak functions it comes in handy though.
Clang-Tidy suggests to prefix the function with '&' to silence its
warning. Doing that revealed a non-obvious behavior in build_ampersand,
which does not add the AMPER node to the expression even though it is
clearly mentioned in the code. That is left for further research.
Once the original bug is fixed, it probably doesn't matter whether the
AMPER is discarded or retained since check_controlling_expression would
add it back. There's probably a reason though to sometimes discard the
AMPER and sometimes retain it.
Don't set BNF in all bold .Ic, instead use .Ar for "expr" and "var" so
that only the literal stuff that is being defined is bold. Arrange
for subscripts to actually be subscripted in PostScript. Make sure
meta-syntactic [] are set differently than literal (). Etc...
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.
