This was introduced in #5279. We were transferring the terminating `\0`
via the pipe and also added another one in the parsing. As we are now
directly writing into a `std::string` these extra characters will now
show up in it. So just get rid of them.
This adds a new checker to check for pointer to bool conversions that
are always known. I removed the previous knownConditionTrueFalse checks
since this was too noisy.
There was no need for the `Tokenizer` parameter to be a pointer as it
could never be `nullptr` and was also dereferenced without checking
first.
As a reference to the `Settings` was already available via the
`Tokenizer` there was no need to pass it separately. In the production
code there will only be one instance of it but in the tests we could
have accidentally passed a different one.
Both are bugprone since they just take the next parameter which doesn't
start with `-`.
Also `--template` has not been documented since
17842394c0 back in 2011(!). And
`--template-location` has never been documented since its induction in
f058d9ad08. That's also why we can have a
short deprecation period.
Both are bugprone since they just take the next parameter which doesn't
start with `-`.
Also `--template` has not been documented since
17842394c0 back in 2011(!). And
`--template-location` has never been documented since its induction in
f058d9ad08. That's also why we can have a
short deprecation period.
It was also used inconsistently and seemed to imply there is some
special handling which wasn't the case. It was just an alias for
`std::to_string()` for non-`double` types. So there was no need for it.
---------
Co-authored-by: Robert Reif <reif@earthlink.net>
In cppcheck 2.11.1 (macOS), using `-j 0` actually causes cppcheck to do
nothing–it stalls indefinitely.
I could only find one place where `mSettings.jobs` was validated against
> 0 and it's simply an assert, so you wouldn't hit it in a release
build.
- Require -j >= 1 ✅
- Cap -j at 1024, not 10000 ✅ (I don't even know what would happen if
you created 10,000 threads, but nothing good; likely exhaust virtual
memory or grind the process to a halt). 1024 is still obscene but there
may be some hypercomputers out there that have that many logical cores.
QT 5 is now completely EOL and since we never supported Qt6 in qmake
which also has various shortcomings, it is time to at least deprecate it
and direct users to CMake instead.
Seems current code for worker threads termination is too brutal which
leads to crash on termination:
```
QThread::start: Thread termination error: No such process
Segmentation fault (core dumped)
```
Seems better to use `quit()` and `wait()`, like in an example:
https://doc.qt.io/qt-6/qthread.html#details
tested: Ubuntu Linux 20
andymacg
Oliver Stöneberg
chrchr-github
Paul Fultz II
Ryan M. Lederman
Anton Lindqvist
Maksim Derbasov