[PATCH 0/9] Some more static checker fixes
This series includes a number of fixes related to the static checkers: * Fedora 40 has updated to Cppcheck 2.14.1 which introduces some new warnings. Fix them. * Jon's recent patch caused a small cppcheck regression. I assume neither Jon nor Stefano is using sufficiently recent cppcheck versions to catch it. Fix that too. * We were disabling the bugprone-macro parentheses check in clang-tidy. I don't think that's a good idea. Re-enable it and fix existing warnings. * It might also be a good idea to enable the bugprone-narrowing-conversions check. Fix a number of issues across the tree which, amongst other things trigger that warning. There are lots of other places that trigger the warning which I haven't fixed yet, so don't enable it yet. David Gibson (9): tcp: Make pointer const in tcp_revert_seq udp: Make rport calculation more local cppcheck: Suppress constParameterCallback errors Remove pointless macro parameters in CALL_PROTO_HANDLER clang-tidy: Enable the bugprone-macro-parentheses check util: Use unsigned indices for bits in bitmaps conf: Safer parsing of MAC addresses lineread: Use ssize_t for line lengths util: Use 'long' to represent millisecond durations Makefile | 3 +-- conf.c | 55 +++++++++++++++++++++++++++++++++++----------------- lineread.c | 10 ++++------ lineread.h | 7 ++++--- passt.c | 6 +++--- tap.c | 37 ++++++++++++++++++----------------- tcp.c | 10 +++++----- tcp_splice.c | 4 ++-- udp.c | 3 +-- util.c | 10 +++++----- util.h | 8 ++++---- 11 files changed, 85 insertions(+), 68 deletions(-) -- 2.45.2
The th pointer could be const, which causes a cppcheck warning on at least
some cppcheck versions (e.g. Cppcheck 2.13.0 in Fedora 40).
Fixes: e84a01e94 "tcp: move seq_to_tap update to when frame is queued"
Signed-off-by: David Gibson
cppcheck 2.14.1 complains about the rport variable not being in as small
as scope as it could be. It's also only used once, so we might as well
just open code the calculation for it.
Signed-off-by: David Gibson
We have several functions which are used as callbacks for NS_CALL() which
only read their void * parameter, they don't write it. The new
constParameterCallback warning in cppcheck 2.14.1 complains that this
parameter could be const void *, also pointing out that that would require
casting the function pointer when used as a callback.
Casting the function pointers seems substantially uglier than using a
non-const void * as the parameter, especially since in each case we cast
the void * to a const pointer of specific type immediately. So, suppress
that error from cppcheck.
Signed-off-by: David Gibson
On Thu, 6 Jun 2024 20:09:43 +1000
David Gibson
We have several functions which are used as callbacks for NS_CALL() which only read their void * parameter, they don't write it. The new constParameterCallback warning in cppcheck 2.14.1 complains that this parameter could be const void *, also pointing out that that would require casting the function pointer when used as a callback.
Casting the function pointers seems substantially uglier than using a non-const void * as the parameter, especially since in each case we cast the void * to a const pointer of specific type immediately. So, suppress that error from cppcheck.
Signed-off-by: David Gibson
--- Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/Makefile b/Makefile index 8ea17576..22f05813 100644 --- a/Makefile +++ b/Makefile @@ -314,5 +314,6 @@ cppcheck: $(SRCS) $(HEADERS) $(SYSTEM_INCLUDES:%=--suppress=unmatchedSuppression:%/*) \ --inline-suppr \ --suppress=unusedStructMember \ + --suppress=constParameterCallback \
On versions before 2.14, this now raises an unmatchedSuppression... I'm not sure how to deal with this. Should we give up and just add a --suppress=unmatchedSuppression for all the source files? I can't think of anything better at the moment. I applied the rest of the series, just not this patch. -- Stefano
On Fri, Jun 07, 2024 at 08:49:40PM +0200, Stefano Brivio wrote:
On Thu, 6 Jun 2024 20:09:43 +1000 David Gibson
wrote: We have several functions which are used as callbacks for NS_CALL() which only read their void * parameter, they don't write it. The new constParameterCallback warning in cppcheck 2.14.1 complains that this parameter could be const void *, also pointing out that that would require casting the function pointer when used as a callback.
Casting the function pointers seems substantially uglier than using a non-const void * as the parameter, especially since in each case we cast the void * to a const pointer of specific type immediately. So, suppress that error from cppcheck.
Signed-off-by: David Gibson
--- Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/Makefile b/Makefile index 8ea17576..22f05813 100644 --- a/Makefile +++ b/Makefile @@ -314,5 +314,6 @@ cppcheck: $(SRCS) $(HEADERS) $(SYSTEM_INCLUDES:%=--suppress=unmatchedSuppression:%/*) \ --inline-suppr \ --suppress=unusedStructMember \ + --suppress=constParameterCallback \
On versions before 2.14, this now raises an unmatchedSuppression... I'm not sure how to deal with this. Should we give up and just add a --suppress=unmatchedSuppression for all the source files? I can't think of anything better at the moment.
No, I don't think we want to do that, that's likely to leave stale suppressions about. Although it logically makes sense to suppress this globally, there are only three spots it actually occurs, so I'll rewrite to suppress in just those places, along with a similarly local unmatchedSuppression suppression.
I applied the rest of the series, just not this patch.
Nice.. although this was the only one actually blocking other work. -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson
On Sat, 8 Jun 2024 16:32:22 +1000
David Gibson
On Fri, Jun 07, 2024 at 08:49:40PM +0200, Stefano Brivio wrote:
On Thu, 6 Jun 2024 20:09:43 +1000 David Gibson
wrote: We have several functions which are used as callbacks for NS_CALL() which only read their void * parameter, they don't write it. The new constParameterCallback warning in cppcheck 2.14.1 complains that this parameter could be const void *, also pointing out that that would require casting the function pointer when used as a callback.
Casting the function pointers seems substantially uglier than using a non-const void * as the parameter, especially since in each case we cast the void * to a const pointer of specific type immediately. So, suppress that error from cppcheck.
Signed-off-by: David Gibson
--- Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/Makefile b/Makefile index 8ea17576..22f05813 100644 --- a/Makefile +++ b/Makefile @@ -314,5 +314,6 @@ cppcheck: $(SRCS) $(HEADERS) $(SYSTEM_INCLUDES:%=--suppress=unmatchedSuppression:%/*) \ --inline-suppr \ --suppress=unusedStructMember \ + --suppress=constParameterCallback \
On versions before 2.14, this now raises an unmatchedSuppression... I'm not sure how to deal with this. Should we give up and just add a --suppress=unmatchedSuppression for all the source files? I can't think of anything better at the moment.
No, I don't think we want to do that, that's likely to leave stale suppressions about.
Although it logically makes sense to suppress this globally, there are only three spots it actually occurs, so I'll rewrite to suppress in just those places, along with a similarly local unmatchedSuppression suppression.
Oh, you're right, I instinctively thought it would be a much bigger mess, I didn't even try.
I applied the rest of the series, just not this patch.
Nice.. although this was the only one actually blocking other work.
...of course. :) I just applied the new patch. -- Stefano
The 'c' parameter is always passed exactly 'c'. The 'now' parameter is
always passed exactly 'now'.
Signed-off-by: David Gibson
We globally disabled this, with a justification lumped together with
several checks about braces. They don't really go together, the others
are essentially a stylistic choice which doesn't match our style. Omitting
brackets on macro parameters can lead to real and hard to track down bugs
if an expression is ever passed to the macro instead of a plain identifier.
We've only gotten away with the macros which trigger the warning, because
of other conventions its been unlikely to invoke them with anything other
than a simple identifier. Fix the macros, and enable the warning for the
future.
Signed-off-by: David Gibson
A negative bit index in a bitmap doesn't make sense. Avoid this by
construction by using unsigned indices. While we're there adjust
bitmap_isset() to return a bool instead of an int.
Signed-off-by: David Gibson
In conf() we parse a MAC address in two places, for the --ns-mac-addr and
the -M options. As well as duplicating code, the logic for this parsing
has several bugs:
* The most serious is that if the given string is shorter than a MAC
address should be, we'll access past the end of it.
* We don't check the endptr supplied by strtol() which means we could
ignore certain erroneous contents
* We never check the separator characters between each octet
* We ignore certain sorts of garbage that follow the MAC address
Correct all these bugs in a new parse_mac() helper.
Signed-off-by: David Gibson
Functions and structures in lineread.c use plain int to record and report
the length of lines we receive. This means we truncate the result from
read(2) in some circumstances. Use ssize_t to avoid that.
Signed-off-by: David Gibson
timespec_diff_ms() returns an int representing a duration in milliseconds.
This will overflow in about 25 days when an int is 32 bits. The way we
use this function, we're probably not going to get a result that long, but
it's not outrageously implausible. Use a long for safety.
Signed-off-by: David Gibson
participants (2)
-
David Gibson
-
Stefano Brivio