[PATCH 0/4] RFC: Updates for cppcheck-2.12 warnings
cppcheck 2.12 (which Fedora 38 has updated, for one) introduces a number of new warnings. Unfortunately, at least one of these is a clear bug in cppcheck. This series fixes a number of the new warnings reported in passt (patches 1..3) and works around the remaining cppcheck bug (patch 4). I'm pretty confident that patches 1 & 2 are safe and beneficial to apply regardless of which cppcheck we're using. Patch 3 is a little more dubious, because it potentially increases the cppcheck runtime. On my system it doesn't seem to make a significant difference, but that might not always stay true. Patch 4 is a tricky one. It applies a specific suppression to work around the cppcheck bug. That's necessary to get a pass with the currently available cppcheck. However, it's ugly and we'd like to remove it once the bug is fixed, but have no obvious way to remind us to do that. What we want to do here kind of depends how long it takes the bug to be fixed, which isn't clear at the moment. David Gibson (4): cppcheck: Make many pointers const conf: Remove overly cryptic selection of forward table cppcheck: Use "exhaustive" level checking when available cppcheck: Work around bug in cppcheck 2.12.0 Makefile | 6 ++++++ conf.c | 25 +++++++++++-------------- isolation.c | 2 +- isolation.h | 2 +- log.c | 6 +++--- netlink.c | 6 +++--- netlink.h | 6 +++--- pasta.c | 4 ++-- pasta.h | 2 +- tap.c | 14 +++++++------- tap.h | 6 +++--- tcp.c | 25 ++++++++++++++++--------- tcp_conn.h | 2 +- tcp_splice.c | 5 +++-- tcp_splice.h | 3 ++- udp.c | 4 ++-- udp.h | 2 +- util.c | 5 +++-- util.h | 4 ++-- 19 files changed, 71 insertions(+), 58 deletions(-) -- 2.41.0
Newer versions of cppcheck (as of 2.12.0, at least) added a warning for
pointers which could be declared to point at const data, but aren't.
Based on that, make many pointers throughout the codebase const.
Signed-off-by: David Gibson
In a couple of places in conf(), we use a local 'fwd' variable to reference
one of our forwarding tables. The value depends on which command line
option we're currently looking at, and is initialized rather cryptically
from an assignment side-effect within the if condition checking that
option.
Newer versions of cppcheck complain about this assignment being an always
true condition, but in any case it's both clearer and slightly shorter to
use separate if branches for the two cases and set the forwarding parameter
more directly.
Signed-off-by: David Gibson
Recent enough cppcheck versions (at least as of cppcheck 2.12) give this
error processing conf.c:
conf.c:1179:1: information: ValueFlow analysis is limited in conf. Use --check-level=exhaustive if full analysis is wanted. [checkLevelNormal]
Adding --check-level=exhaustive doesn't seem to significantly increase the
cppcheck run time for us, so enable it when possible, suppressing that
warning.
Signed-off-by: David Gibson
cppcheck 2.12.0 (and maybe some other versions) things this if condition
is always true, which is demonstrably not true. Work around the bug for
now.
Signed-off-by: David Gibson
On Fri, Sep 29, 2023 at 03:50:18PM +1000, David Gibson wrote:
cppcheck 2.12 (which Fedora 38 has updated, for one) introduces a number of new warnings. Unfortunately, at least one of these is a clear bug in cppcheck.
This series fixes a number of the new warnings reported in passt (patches 1..3) and works around the remaining cppcheck bug (patch 4). I'm pretty confident that patches 1 & 2 are safe and beneficial to apply regardless of which cppcheck we're using.
Patch 3 is a little more dubious, because it potentially increases the cppcheck runtime. On my system it doesn't seem to make a significant difference, but that might not always stay true.
Patch 4 is a tricky one. It applies a specific suppression to work around the cppcheck bug. That's necessary to get a pass with the currently available cppcheck. However, it's ugly and we'd like to remove it once the bug is fixed, but have no obvious way to remind us to do that. What we want to do here kind of depends how long it takes the bug to be fixed, which isn't clear at the moment.
Forgot to mention that this was based on the siphash series, although I don't think it will have any conflicts.
David Gibson (4): cppcheck: Make many pointers const conf: Remove overly cryptic selection of forward table cppcheck: Use "exhaustive" level checking when available cppcheck: Work around bug in cppcheck 2.12.0
Makefile | 6 ++++++ conf.c | 25 +++++++++++-------------- isolation.c | 2 +- isolation.h | 2 +- log.c | 6 +++--- netlink.c | 6 +++--- netlink.h | 6 +++--- pasta.c | 4 ++-- pasta.h | 2 +- tap.c | 14 +++++++------- tap.h | 6 +++--- tcp.c | 25 ++++++++++++++++--------- tcp_conn.h | 2 +- tcp_splice.c | 5 +++-- tcp_splice.h | 3 ++- udp.c | 4 ++-- udp.h | 2 +- util.c | 5 +++-- util.h | 4 ++-- 19 files changed, 71 insertions(+), 58 deletions(-)
-- 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 Fri, 29 Sep 2023 15:50:18 +1000
David Gibson
cppcheck 2.12 (which Fedora 38 has updated, for one) introduces a number of new warnings. Unfortunately, at least one of these is a clear bug in cppcheck.
This series fixes a number of the new warnings reported in passt (patches 1..3) and works around the remaining cppcheck bug (patch 4). I'm pretty confident that patches 1 & 2 are safe and beneficial to apply regardless of which cppcheck we're using.
Patch 3 is a little more dubious, because it potentially increases the cppcheck runtime. On my system it doesn't seem to make a significant difference, but that might not always stay true.
On my system, it's 23 seconds instead of 21... I don't really see a problem with that.
Patch 4 is a tricky one. It applies a specific suppression to work around the cppcheck bug. That's necessary to get a pass with the currently available cppcheck. However, it's ugly and we'd like to remove it once the bug is fixed, but have no obvious way to remind us to do that. What we want to do here kind of depends how long it takes the bug to be fixed, which isn't clear at the moment.
I don't see a big issue with this either, we already have one suppression like that in tcp_clamp_window() where we kind of identified the issue but it hasn't been solved yet. Once it's fixed, we'll hopefully notice and drop the suppression if cppcheck 2.12 is old enough by then, but if we don't, I don't think it's a drama. The whole series looks good to me by the way. -- Stefano
On Fri, Sep 29, 2023 at 05:31:34PM +0200, Stefano Brivio wrote:
On Fri, 29 Sep 2023 15:50:18 +1000 David Gibson
wrote: cppcheck 2.12 (which Fedora 38 has updated, for one) introduces a number of new warnings. Unfortunately, at least one of these is a clear bug in cppcheck.
This series fixes a number of the new warnings reported in passt (patches 1..3) and works around the remaining cppcheck bug (patch 4). I'm pretty confident that patches 1 & 2 are safe and beneficial to apply regardless of which cppcheck we're using.
Patch 3 is a little more dubious, because it potentially increases the cppcheck runtime. On my system it doesn't seem to make a significant difference, but that might not always stay true.
On my system, it's 23 seconds instead of 21... I don't really see a problem with that.
Right, it's like 16s vs 15s for me. I was just a bit concerned they might add more, very expensive tests under the "exhaustive" set later on.
Patch 4 is a tricky one. It applies a specific suppression to work around the cppcheck bug. That's necessary to get a pass with the currently available cppcheck. However, it's ugly and we'd like to remove it once the bug is fixed, but have no obvious way to remind us to do that. What we want to do here kind of depends how long it takes the bug to be fixed, which isn't clear at the moment.
I don't see a big issue with this either, we already have one suppression like that in tcp_clamp_window() where we kind of identified the issue but it hasn't been solved yet.
Once it's fixed, we'll hopefully notice and drop the suppression if cppcheck 2.12 is old enough by then, but if we don't, I don't think it's a drama.
The whole series looks good to me by the way.
Ok. Well, apply whenever you're ready then, I guess. -- 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 Tue, 3 Oct 2023 13:36:12 +1100
David Gibson
On Fri, Sep 29, 2023 at 05:31:34PM +0200, Stefano Brivio wrote:
On Fri, 29 Sep 2023 15:50:18 +1000 David Gibson
wrote: cppcheck 2.12 (which Fedora 38 has updated, for one) introduces a number of new warnings. Unfortunately, at least one of these is a clear bug in cppcheck.
This series fixes a number of the new warnings reported in passt (patches 1..3) and works around the remaining cppcheck bug (patch 4). I'm pretty confident that patches 1 & 2 are safe and beneficial to apply regardless of which cppcheck we're using.
Patch 3 is a little more dubious, because it potentially increases the cppcheck runtime. On my system it doesn't seem to make a significant difference, but that might not always stay true.
On my system, it's 23 seconds instead of 21... I don't really see a problem with that.
Right, it's like 16s vs 15s for me. I was just a bit concerned they might add more, very expensive tests under the "exhaustive" set later on.
Patch 4 is a tricky one. It applies a specific suppression to work around the cppcheck bug. That's necessary to get a pass with the currently available cppcheck. However, it's ugly and we'd like to remove it once the bug is fixed, but have no obvious way to remind us to do that. What we want to do here kind of depends how long it takes the bug to be fixed, which isn't clear at the moment.
I don't see a big issue with this either, we already have one suppression like that in tcp_clamp_window() where we kind of identified the issue but it hasn't been solved yet.
Once it's fixed, we'll hopefully notice and drop the suppression if cppcheck 2.12 is old enough by then, but if we don't, I don't think it's a drama.
The whole series looks good to me by the way.
Ok. Well, apply whenever you're ready then, I guess.
Sure, applied now. -- Stefano
participants (2)
-
David Gibson
-
Stefano Brivio