Relative argument paths on Windows

[TheOtherMarcus]

I'm on Windows. I would like to use parameter paths relative to my project.

"cppcheck-official.arguments": "--platform=./CppCheck/platform.xml"

I understand this doesn't work. I then tried running a script to generate parameters

"cppcheck-official.arguments": "@(./CppCheck/plugin_arguments.cmd)"

but I can't get this script to run, even when using an absolute path.

I also tried with a wrapper to cppcheck itself

"cppcheck-official.path": "./CppCheck/plugin_wrapper.cmd"

@echo off

REM Find project root (parent of this script directory)
set ROOT="%~dp0\.."

echo -- >>%ROOT%\args
echo %* >>%ROOT%\args

REM Run cppcheck with all passed arguments
"C:\Program Files\CppCheck Premium\cppcheck.exe" %*

The script is invoked once with the parameter "--version", then silence.

Any ideas?

[TheOtherMarcus]

Alright, I have to use ${...} in v1.0.4. At least the argument generation works. But I have found a new problem.

child_process.exec() does not parse quoted strings like the shell does. Quotes end up in argv and cppcheck doesn't like that for obvious reasons.

cppcheck --platform="path to\platform.xml"

Normally the shell parses this to argv ['cppcheck', '--platform=path to\platform.xml']

but child_process.exec() gives us argv ['cppcheck', '--platform="path to\platform.xml"']

A solution would be to use spawn() instead. It wants the arguments separated in a list, which we should do already in settings.json:

"cppcheck-official.arguments": ["arg1", "arg2"]

[TheOtherMarcus]

I tried to run with a --project I created with cppcheckgui, and it seems to be invoked because it changes files in the project build dir. The only result I get is one #error Unknown compiler. on a random line.

[jgeudens]

Hi, I'm also struggling to get this working. I want to specify an addon with custom rules. I have noticed that the cppcheck extension handles the paths differently when --project is specified or not.

Since I have no knowledge of Typescript, I have asked an AI assistant to investigate. I hope you don't mind information generated by AI.

Bug: Relative addon paths may not resolve correctly

What happens

When --addon=./my_addon.py (or any relative path) is passed via the cppcheck-official.arguments setting, the extension appears to forward it to cppcheck unchanged. Cppcheck then resolves the path relative to its own working directory (CWD), which the extension sets differently depending on context:

• With --project: CWD = directory of the currently-analysed file (path.dirname(document.fileName))
• Without --project: CWD = workspace root

In the --project case, the addon path would be relative to a per-file directory that changes per document, which could cause cppcheck to silently fail to find the addon.

Possible root cause

In src/extension.ts:188-195, the argument-parsing step only applies path resolution to --project arguments:

const argsParsed = processedArgs.split(" ").map((arg) => {
    if (arg.startsWith('--project')) {
        const splitArg = arg.split('=');
        return `${splitArg[0]}=${resolvePath(splitArg[1])}`;
    }
    return arg; // --addon and other path-taking flags pass through untouched
});

The resolvePath() utility in src/util/path.ts already handles ${workspaceFolder}, ~, ./, ../, and bare workspace-relative paths — it just does not appear to be called for --addon.

Potential fix

Adding a similar branch for --addon in the same map. One thing worth considering: cppcheck addons can be specified as either a file path (./addons/cert.py) or a built-in name (cert, misra). Calling resolvePath("cert") would likely turn it into /workspace/cert, breaking built-in addon names. Path resolution would probably only need to apply when the value contains a path separator, ~, or ${workspaceFolder}.

Possibly affected flags

--addon is the reported case. --suppressions-list, --rule-file, and --include may have the same issue.

[davidramnero]

These are 2 different issues described by @TheOtherMarcus and @jgeudens. I will take a look at both asap!

[danmar]

@TheOtherMarcus @jgeudens thank you very much for the bug reports! Please keep reporting bugs, we will prioritize fixing them.