The previous names tspec_is_int and tspec_is_uint were confusing because
there are actually tspec_t constants called INT and UINT, these
classification macros return true for other integer types as well,
though.
While here, remove the prefix "tspec_" from these macros. It wasn't as
helpful as intended, in many cases it was obviously redundant, when it
was called as tspec_is_integer(tn->tn_type->t_tspec).
No functional change.
Contrary to the comment in typeok, the types of the expressions before
promotions and conversions are not needed for SHL, SHLASS and SHRASS.
Move that code over to typeok_shr, the only place where it is actually
used. This removes another 3 variables from typeok.
The code in typeok is already complicated enough. Only few of the
checks actually examine the subtype of the pointer, the others don't
need to look at it. Therefore don't initialize the variables lstp
(left-hand side subtype) and rstp unless they are actually needed.
This reduces the number of variables in typeok and the number of
parameters to the sub-functions.
The C preprocessor does not require its arguments to be expressions, an
empty string is valid as well. This allows to replace the 0 in the
operator properties table with a space, making the 1 stick out.
Since the table is quite long, divide it into sections and add section
headers.
No change in the generated code.
The file ops.c had previously been autogenerated. This meant that in a
NetBSD build, it was generated in OBJDIR, and a build that had just
updated src/usr.bin would fail. For a build that last ran on
2020-12-01, and again today, it looks like this:
# link lint1/lint1
cc ... -o lint1 cgram.lo ... ops.lo ... tyname.lo
/usr/bin/ld: ops.lo: in function `initmtab':
ops.c:(.text+0x63): undefined reference to `STRUCT_ASSIGN'
This is caused by ops.c existing in OBJDIR, so the new version in
NETBSDSRCDIR is not looked at. To prevent this, use oper.c instead as
the filename, which has not been used before.
https://mail-index.netbsd.org/source-changes-d/2021/01/09/msg013096.html
If lint is run on a platform that has CHAR_BIT == 10, this doesn't
magically make an ILP32 platform have 40 bits per uint32_t.
At the moment, all of the supported platforms are either ILP32 or
I32LP64 anyway, and all of them have CHAR_BIT == 8 == CHAR_SIZE,
so nothing changes practically.
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.
- 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.
