This is in preparation of avoiding accessing `std::cout` directly as
well as streamlining and improving the logging during the settings
parsing. There are no functional changes yet.
This makes the code much more readable. It also makes it less prone to
errors because we do not need to specify the length of the string to
match and the returnvalue is clear.
The code with the bad returnvalue check was never executed and I added a
test to show that.
Windows XP Pro x64 was released on April 25, 2005 and consumer
processors supporting x86-64 have been around almost as long. Although
there are still 32-bit Windows images available there is not much of a
point maintaining support for these. We also never did any x86 builds
for non-Windows platforms in CI so we don't even know if we work on
those. You might still be able to build 32-bit binaries via CMake.
Encountered while investigating https://trac.cppcheck.net/ticket/11708.
This has been like this since the introduction of `internalError` in
b6bcdf2936 (almost ten years ago to the
day). Logging internal errors which bail out(!) of the analysis simply
to `std::cout` for them possibly never to be seen (and also not affected
the exitcode) is pretty bad IMO. They should always be visible.
I also removed the filename from the message as it is already available
(and thus redundant) and its existence should be defined by the
template.
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.
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.
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.
This starts to untangle the `ErrorLogger` implementation in
`CppcheckExecutor` which handles three different cases and makes things
unnecessarily complicated.
Cppcheck does not report that cppcheck build dir does not exist and also
does not report any write issues to the non-existent directory.
This means that cppcheck build dir is actually not used.
We should either create the directory or fail.
This is a mess. The version is AUR is still outdated and also doesn't
install anymore. Fedora 38 carries the latest version of it so use that
now. Keep the old steps in case we need to switch again in the future.
* Use path to executable when trying to load library
* Fix function call, add support for more OS, add test
* Format
* Handle MacOS
* Amend
* Argument as fallback
* Use Path::getCurrentExecutablePath()
* Move to cmdlineparser.cpp
* Debug output
* Use argv[0] in Cygwin
* Revert "Debug output"
This reverts commit 5a68d71f1d27549c7b4a46363f3cd5cd912018e7.
* Use native python in Cygwin
* SingleExecutor: added TODOs
* test `SingleExecutor` with files and project
* SingleExecutor: process markup files after code when scanning project
* TestSingleExecutor: generate scoped files before calling executor
* CI-unixish.yml: added `--output-on-failure` to CTest call
* helpers.cpp: improved error reporting in `~ScopedFile()`
* use unique filenames in executor tests to avoid collisions
* fixed `functionStatic` selfcheck warnings
Oliver Stöneberg
Daniel Marjamäki
chrchr-github
Ryan M. Lederman
Samuel Poláček
Long Radix