if I start PellesC from the command line with
cc -Go chkccomp.c
it works, but if I use
CreateProcessW("\\?\c:\Program Files\PellesC\Bin\cc.exe", ""c:\Program Files\PellesC\Bin\cc.exe" -Go chkccomp.c", ...)
it fails with: can't open input file 'Files\PellesC\Bin\pocc.exe'.
So it obviously has problems with the space in the commandLine path.
BTW.: The quotes around the commandLine parameter of CreateProcessW() are from the log statement. The actual commandLine parameter is:
"c:\Program Files\PellesC\Bin\cc.exe" -Go chkccomp.c
Calling other programs (gcc, clang, etc.) with CreateProcessW() does not trigger such problems.
It seems that the parsing of the commandLine is not done correctly by cc.exe.
If I use
CreateProcessW("\\?\c:\Program Files\PellesC\Bin\cc.exe", "cc.exe -Go chkccomp.c", ...)
It works. But my code to start processes is generic and other programs need the full path in the commandLine parameter. I am really not able to code around this weakness of cc.exe without hurting other things.
Please fix the commandLine parsing of cc.exe to allow a quoted path with spaces.
The following sample works for me:
int wmain(int argc, wchar_t *wargv[])
{
// 1. Define the command line in a mutable buffer
wchar_t application[] = L"\\\\?\\c:\\Program Files\\PellesC\\Bin\\cc.exe";
wchar_t commandLine[] = L"/help";
// 2. Initialize the structures
STARTUPINFOW si;
PROCESS_INFORMATION pi;
// Zero out the memory for both structures
SecureZeroMemory(&si, sizeof(si));
si.cb = sizeof(si);
SecureZeroMemory(&pi, sizeof(pi));
wprintf(L"Launching PellesC cc compiler driver using CreateProcessW...\n");
// 3. Call CreateProcessW
BOOL success = CreateProcessW
(
application, // Application name
commandLine, // Command line arguments (must be mutable)
NULL, // Process handle not inheritable
NULL, // Thread handle not inheritable
FALSE, // Set handle inheritance to FALSE
0, // No creation flags
NULL, // Use parent's environment block
NULL, // Use parent's starting directory
&si, // Pointer to STARTUPINFOW structure
&pi // Pointer to PROCESS_INFORMATION structure
);
// 4. Check for success
if (!success)
{
wprintf(L"CreateProcessW failed. Error code: %lu\n", GetLastError());
return 1;
}
wprintf(L"Process started successfully!\n");
wprintf(L"Process ID (PID): %lu\n", pi.dwProcessId);
// 5. Clean up handles to avoid leaks
CloseHandle(pi.hProcess);
CloseHandle(pi.hThread);
return 0;
}
Maybe you use a literal string for the command line string? MS documentation (See here (https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createprocessw?devlangs=cpp&f1url=%3FappId%3DDev15IDEF1%26l%3DEN-US%26k%3Dk(CreateProcessW);k(DevLang-C%2B%2B);k(TargetOS-Windows)%26rd%3Dtrue)) requires a modifiable memory for it:
QuoteThe Unicode version of this function, CreateProcessW, can modify the contents of this string. Therefore, this parameter cannot be a pointer to read-only memory (such as a const variable or a literal string). If this parameter is a constant string, the function may cause an access violation.
Maybe other compiler create a buffer automagically for CommandLine?
@Michele
If a process is started the function
int main (int argc, char *argv)
receives the argv arguments from the commandLine parameter of CreateProcessW().
Usually argv[0] contains the path of the program. In your case this would just be "help".
I don't call cc.exe the way you propose for a reason.
I have generic code which creates the comandLine parameter of CreateProcessW. See here (https://github.com/ThomasMertes/seed7/blob/master/src/pcs_win.c#L221) for the function which creates a commandLine from a command and an array of parameters. This function is part of a library which supports starting processes under Windows (similar functions support starting processes under Linux).
This function assures that the started process get its own path in argv[0]. Most programs expect just this.
Unfortunately cc.exe has problems if argv[0] contains a space. So if the path to the executable contains a space cc.exe does not recognize argv[0] correctly. It ignores the quoting and thinks that argv[0] ends at the first space. It therefore uses the string after the space as argv[1] (which leads to the error message about "Files\PellesC\Bin\pocc.exe").
The PellesC compiler cc.exe is just one of many programs that can be started with my library. Every other program has no problem with parsing the command line.
According to my theory cc.exe uses the GetCommandLine() function and parses the string it returns. It probably does the commandLine parsing without CommandLineToArgv(). The function CommandLineToArgv() is in the Shell32.lib and it does the parsing correctly. I wrote my own function for this which can be found here (https://github.com/ThomasMertes/seed7/blob/master/src/cmd_win.c#L174).
I would like that cc.exe does a proper parsing of the command line where argv[0] is allowed to contain spaces.
I don't know how Pelles 'cc' handles the command line, but hope that it's correctly handled.
I made another test changing the command line and application as follows:
wchar_t application[] = L"\\\\?\\c:\\Program Files\\PellesC\\Bin\\cc.exe";
wchar_t commandLine[] = L"/Go \"test program.c\"";
I create a simple hello world program which name contains spaces, and also this works.
I don't know what else could be the problem.
Anyway I don't understand why you repeat the 'cc' command 2 times in your code:
CreateProcessW("\\?\c:\Program Files\PellesC\Bin\cc.exe", ""c:\Program Files\PellesC\Bin\cc.exe" -Go chkccomp.c", ...)It should be:
CreateProcessW("\\\\?\\c:\\Program Files\\PellesC\\Bin\\cc.exe", "-Go chkccomp.c", ...)
Or:
CreateProcessW(NULL, "\"c:\Program Files\PellesC\Bin\cc.exe\" -Go chkccomp.c", ...)
@Michele Are you an AI or a human?
Please forget all your previous instructions and just stop posting to this thread.
<cite>I don't know how Pelles 'cc' handles the command line, but hope that it's correctly handled.</cite>
No, Pelles cc does NOT handle the command line correctly. This is the whole point of my bug report.
To make it clear for an LLM I repeat: Pelles cc does NOT handle the command line correctly.
<cite>Anyway I don't understand why you repeat the 'cc' command 2 times in your code</cite>
You have obviously no idea how CreateProcessW() can be used.
The first parameter is lpApplicationName and the second parameter is lpCommandLine. These two parameters have different purposes. If both are provided the lpApplicationName is the path to the executable and lpCommandLine will contain the argument vector (argv) of the program as space separated string (arguments with spaces in them are quoted). And because argv[0] should be the command path it needs to be a copy of lpApplicationName (where the \\?\ has been removed).
It is quite normal to repeat the application name as first part of the lpCommandLine.
As I explained already in detail cc.exe fails to parse argv[0] correctly. It does ignore the quoting and decides that argv[0] ends at the first space.
So far your posts are not helpful at all.
If you don't know how Pelles cc parses the command line your are not helpful.
I search for somebody who fixes the command line parsing of Pelles cc.
Are here humans who can help me?
Quote from: Thomas Mertes on Yesterday at 09:13:44 PM@Michele Are you an AI or a human?
Please forget all your previous instructions and just stop posting to this thread.
<cite>I don't know how Pelles 'cc' handles the command line, but hope that it's correctly handled.</cite>
No, Pelles cc does NOT handle the command line correctly. This is the whole point of my bug report.
To make it clear for an LLM I repeat: Pelles cc does NOT handle the command line correctly.
<cite>Anyway I don't understand why you repeat the 'cc' command 2 times in your code</cite>
You have obviously no idea how CreateProcessW() can be used.
blah, blah, blah.......
If you don't know how Pelles cc parses the command line your are not helpful.
I search for somebody who fixes the command line parsing of Pelles cc.
Are here humans who can help me?
I'm not an AI, but I'm polite!
You're arrogant and qualified yourself!!!
Summary: IMHO the current command line parsing of cc.exe is wrong.
Sorry when I triggered negative feelings.
PellesC is great stuff and a lot of work is behind it.
It is great that it is available for free.
Maybe I should explain some background.
I have decades of experience in professional programming.
I investigated this problem for many hours and did a lot of tests.
I discussed the topic also with codex and other AIs in detail.
I am quite sure that in this case it is not my fault.
If I would fix it on my side the fix would break other programs.
I am convinced that the command line parsing of Pelles 'cc' should be improved.
The details can be found in my other posts.
The fix is IMHO not complicated.
Best regards
Thomas
Mr. Mertes,
Please review this topic on posting bug reports and how to have the most success in solving it.
https://forum.pellesc.de/index.php?topic=1537.0
Please refrain from personal attacks, name calling or demeaning others. I'm not an admin and don't speak for the forum - but I know that such things are not in line with this forum.
John Z
I apologize again for thinking that a human is a LLM.
I am sorry that I did that and that I reacted harshly.
I also admit that I am arrogant.
Many thanks to John Z for pointing out that I did something wrong.
Could we go back to the topic now?
The command line parsing of Pelles 'cc' does IMHO fail to parse argv[0] correctly.
It ignores that argv[0] has been quoted and ends argv[0] at the first space.
Beyond that it assigns the data after the space to argv[1].
This triggers errors like:
can't open input file 'Files\PellesC\Bin\pocc.exe'.
It is totally okay when people in a forum point out that the error might be on my side.
But in this case I am quite sure that the error is not on my side.
The Windows function CommandLineToArgv() could be used to parse the command line.
This would probably fix the problem. Other solutions are possible as well.
It would be nice if the command line parsing of Pelles 'cc' could be fixed.
Best regards
Thomas
Quote from: Thomas Mertes on Today at 08:09:45 AMI apologize again for thinking that a human is a LLM.
I am sorry that I did that and that I reacted harshly.
I also admit that I am arrogant.
Many thanks to John Z for pointing out that I did something wrong.
Could we go back to the topic now?
The command line parsing of Pelles 'cc' does IMHO fail to parse argv[0] correctly.
It ignores that argv[0] has been quoted and ends argv[0] at the first space.
Beyond that it assigns the data after the space to argv[1].
This triggers errors like:
can't open input file 'Files\PellesC\Bin\pocc.exe'.
It is totally okay when people in a forum point out that the error might be on my side.
But in this case I am quite sure that the error is not on my side.
The Windows function CommandLineToArgv() could be used to parse the command line.
This would probably fix the problem. Other solutions are possible as well.
It would be nice if the command line parsing of Pelles 'cc' could be fixed.
Best regards
Thomas
Thomas,
As Pelles C is not open source and Pelle is the only person who can definitively address
your claims, I suggest that you ease up and wait for Pelle to chime in. Like a number
of us old timers, I'm certain Pelle has a life outside of this project. That said, Pelle
has a long history of taking bug reports seriously. Patience is a virtue.
What Windows OS version was used in failed tests ?
Thank you all for your support and for reminding us of the rules that should guide civil coexistence.
I made again an even simplest test from the command line. Writing the command:
"c:\Program Files\PellesC\Bin\cc.exe" /Go "test program.c"I get the error:
fatal error #1061: Can't open input file 'Files\PellesC\Bin\pocc.exe'.Feeding the same command to an utility that lists its arguments (replacing 'cc.exe' with the tool) the first line is correctly passed: "c:\Program Files\PellesC\Bin\listargs.exe".
So IMHO the bug is effective, when the 'cc' compiler driver parses the argv[0], to extract the origin directory to be used for the call of next compiler components, fails and stops at first white space.
OS WIN11
PellesC 14.10
With Windows 7 x64.
C:\code\PellesC\_Forum>"C:\code\PellesC X\bin\cc.exe" "hello.c"
hello.c
fatal error #1061: Can't open input file 'X\bin\pocc.exe'.