Repository navigation
do not depend on lifetime of user object in TokenList #424
Description
Activity
The mess is even bigger as the vector is also referenced and (potentially) modified in Macro and preprocess().
added 11 commits that reference this issue on Oct 12, 2025
added 7 commits that reference this issue on Oct 20, 2025
https://trac.cppcheck.net/ticket/14268 is an issue in Cppcheck where the object went out of scope.
It appears the functionality of providing a list of existing files is required internally by Macro but not downstream in Cppcheck. I cannot really tell if that is actually necessary yet because the code is quite entangled. So far I have failed at a few attempts at doing incremental cleanups but I also do not have a final state to work back from either.
added a commit that references this issue on Dec 7, 2025
Metadata
Metadata
Assignees
Labels
No labels
TokenListdepends on a mutablestd::vector<std::string>object which holds the files of files which have been tokenized. This seems dangerous as it ties to the lifetime of another object. In some cases this vector is not even necessary to be owned by the user since it is not used outside of theTokenList. It looks the list this could just be owned byTokenListThis supported by the fact that the copy constructors and assignment operators copy the reference which means that two different instances will modify that "global" vector which is obviously wrong and will cause issues.
There was some usage which provides the input file via that vector parameter instead of (or additionally) to the filename parameter. This allows to tokenize multiples explicitly but I am not sure if that is even necessary. This might have contributed to the assumption that it is necessary to provide that vector.