Oliver Stöneberg

I filed https://trac.cppcheck.net/ticket/13223 about a flakey test.

> I filed https://trac.cppcheck.net/ticket/13223 about a flakey test. Turns out it always fails on that specific platform. I cannot reproduce it locally.

See also https://github.com/danmar/cppcheck/pull/7833#issuecomment-3315995504. Using `__int128` it almost fully builds except for the requirement on `ValueFlow::Value::equalTo()` (suggestions on how to address it in this PR are welcome). The conversion to string...

> The conversion to string for actual 128-bit values does not exist yet but this already exposes overflow issues in the existing code. I filed https://trac.cppcheck.net/ticket/14154 about that.

We should also make sure that our scripts also use the stricter behavior. And obviously that should be extended to Cppcheck as well.

There are suppressions in `.selfcheck_unused_suppressions` which need to be removed.

Since https://trac.cppcheck.net/ticket/10661 was also fixed quite a while ago that suppression can also be removed. Let's hope this year we can finally enable `unmatchedSuppression` in our selfchecks...

The remaining "false positive" from that file can probably moved to the source leaving just the intended suppressions.

> After modifying `.selfcheck_unused_suppressions`, we get `analyzeEnumValue(symboldatabase, settings): 0.001s (avg. 0.0005s - 2 result(s))'` on Windows but `Tokenizer::createTokens: 0.001111s (avg. 0.001111s - 1 result(s))` elsewhere. Not sure why. That test...

> Maybe the showtime result is just very sensitive on the execution environment/runner? It is checking the number of invocations of timing steps i.e. the ValueFlow execution. That should be...