Skip to content
Open
Show file tree
Hide file tree
Changes from 3 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
17 changes: 16 additions & 1 deletion lib/suppressions.cpp
Original file line number Diff line number Diff line change
Expand Up @@ -420,7 +420,7 @@ SuppressionList::Suppression::Result SuppressionList::Suppression::isSuppressed(
if (!thisAndNextLine || lineNumber + 1 != errmsg.lineNumber)
return Result::None;
}
if (!fileName.empty() && !PathMatch::match(fileName, errmsg.getFileName()))
if (!fileName.empty() && !isFileNameMatch(errmsg.getFileName()))
return Result::None;
if (hash > 0 && hash != errmsg.hash)
return Result::Checked;
Expand Down Expand Up @@ -453,6 +453,21 @@ SuppressionList::Suppression::Result SuppressionList::Suppression::isSuppressed(
return Result::Matched;
}

bool SuppressionList::Suppression::isFileNameMatch(const std::string &errorFileName) const
{
const auto it = mFileNameMatchCache.find(errorFileName);

@danmar danmar Aug 20, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I fear there could be thread safety issues if two threads call isFileNameMatch at the same time. Could there?
I think either some locking will be needed. Or we need to move the cache data to each analyzer thread.

To complicate things a bit we sometimes run processes and sometimes threads. I am not sure how this will work when processes are used but I assume this cache will only work per-process then, each process will get its own cache..

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for your feedback.

A std::map is not thread safe, so if multiple threads can/will update it at the same time then it must be protected by a mutex.
The other members of the Suppression class are not protected by a lock, which is why I didn't create one in the first place, but I suppose this could be because they are either primitive types or are only written to during initial creation of a suppression.

I see no problem with each process having it's own cache (if that is the case) because it will still reduce the total amount of calls to PathMatch::match, which is the whole goal with the cache.

I will work on a mutex to protect the cache to eliminate any concerns about thread safety issues.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I spent time some time looking at the code again, and the cache - including all other members in the Suppression struct/class - are already protected by the mutex declared in SuppressionList.

All calls to Suppression.isFileNameMatch are routed through SuppressionsList.isSuppressed, which acquires the lock.
The only exception is a single place in some test code.
This test code has a todo, which could indicate that it needs to be changed.
Code copied below (see testsuppressions.cpp).

    // TODO: this tests an internal function - should it be private?
    void symbol() const {
        SuppressionList::Suppression s;
        s.fileName = "test.cpp";
        s.errorId = "foo";
        s.symbolName = "array*";

        SuppressionList::ErrorMessage errorMsg;
        errorMsg.errorId = "foo";
        errorMsg.symbolNames = "";
        ASSERT_EQUALS_ENUM(SuppressionList::Suppression::Result::None, s.isSuppressed(errorMsg));
        errorMsg.setFileName("test.cpp");
        errorMsg.lineNumber = 123;
        ASSERT_EQUALS_ENUM(SuppressionList::Suppression::Result::Checked, s.isSuppressed(errorMsg));
        errorMsg.symbolNames = "x\n";
        ASSERT_EQUALS_ENUM(SuppressionList::Suppression::Result::Checked, s.isSuppressed(errorMsg));
        errorMsg.symbolNames = "array1\n";
        ASSERT_EQUALS_ENUM(SuppressionList::Suppression::Result::Matched, s.isSuppressed(errorMsg));
        errorMsg.symbolNames = "x\n"
                               "array2\n";
        ASSERT_EQUALS_ENUM(SuppressionList::Suppression::Result::Matched, s.isSuppressed(errorMsg));
        errorMsg.symbolNames = "array3\n"
                               "x\n";
        ASSERT_EQUALS_ENUM(SuppressionList::Suppression::Result::Matched, s.isSuppressed(errorMsg));
    }

This means that someone has already thought about potential thread safety issues related to the suppression list and handled it accordingly, which is a good thing 👍

if (it != mFileNameMatchCache.end())
return it->second;

const bool result = PathMatch::match(fileName, errorFileName);

if (mFileNameMatchCache.size() >= mFileNameMatchCacheMaxEntries)
mFileNameMatchCache.clear();

mFileNameMatchCache.emplace(errorFileName, result);
return result;
}

bool SuppressionList::Suppression::isMatch(const SuppressionList::ErrorMessage &errmsg)
{
switch (isSuppressed(errmsg)) {
Expand Down
6 changes: 6 additions & 0 deletions lib/suppressions.h
Original file line number Diff line number Diff line change
Expand Up @@ -168,6 +168,12 @@ class CPPCHECKLIB SuppressionList {
bool isPolyspace{};

enum : std::int8_t { NO_LINE = -1 };

private:
bool isFileNameMatch(const std::string &errorFileName) const;

static constexpr std::size_t mFileNameMatchCacheMaxEntries = 256;
mutable std::map<std::string, bool> mFileNameMatchCache;
};

/**
Expand Down
Loading