The code in add_function is severely broken, it mixes up the return type
of the function with the argument types. For now, at least show the
guessed type in the diagnostic, to allow human readers quickly spot the
bug.
Extend the test cases in decl_direct_abstract.c to show that the
behavior differs unreasonably if the first parameter of the function is
equal to its return type.
The syscall only guarantees up to 256 bytes in a single go -- if
interrupted, it might return short, but if the caller requested at
least 256 bytes it will definitely return 256 bytes.
The warning is wrong, and it has been for a long time. For now just fix
the test to match the actual output. Seen on evbarm, which is one of
the platforms where a plain char is unsigned.
Noticed by Martin.
Previously, the string literals "1" "2" "3" "4" were concatenated in the
order "23", "234", "1234". This influenced the location of the
diagnostics for traditional C (which doesn't know concatenation at all)
and for mixing regular strings and wide strings.
Now the diagnostics occur exactly where they are expected. The first
string literal defines whether the whole string is regular or wide, and
any further string literals must match it.
In traditional C mode, there are more diagnostics than before, but that
doesn't hurt since they are still correct and nobody uses lint in
traditional C mode anyway.
This only applies to traditional C and ensures that the behavior is
preserved when rearranging the C parser to evaluate string concatenation
from left to right.
The commit that introduced the assertion failure looks innocent, it only
adds a few predefined functions for GCC mode. Nevertheless, before that
commit, lint consistently complained about 'error: void type illegal in
expression [109]', which doesn't make sense either.
This fix also removes the creative use of the initialization stack to
store the type of the statement expression. Having a separate stack for
these statement expressions makes the code easier to understand.
The solution is not elegant since it adds a small state machine inside
the parser state, but at least these states only depend on the sequence
of token types and not on any other part of the parser state.
Reported in PR#55453.
It seems that alarm(1) is not enough time for the thread to actually exit after quittingtime = 1.
It randomly failed with "Test program received signal 14" on a slow environment.
gson