- Welcome to Pelles C forum.
Pelles C forum
News:
Download Pelles C here: http://www.pellesc.se
Recent posts
#1
Bug reports / Re: Segmentation fault with se...
Last post by MrBcx - May 30, 2026, 04:56:04 PMAnother observation:
If compiled to 32-bit:
In main
malloc successful
okay
If compiled to 64-bit:
In main
malloc successful
unhandled exception
If compiled to 32-bit:
In main
malloc successful
okay
If compiled to 64-bit:
In main
malloc successful
unhandled exception
#2
Bug reports / Re: Segmentation fault with se...
Last post by TimoVJL - May 30, 2026, 09:24:28 AMAn alignment error at memory for jmp_buf at x64
Simple test:
Dynamic jmp_buf should allocated using aligned_alloc() function for x64.
Simple test:
Code Select
catch_type *pcs;
...
catch_stack = (catch_type *)(malloc(max_catch_stack * sizeof(catch_type)+8));
pcs = (catch_type *)(((long long)catch_stack) + ((long long)catch_stack % 16));
printf("%p %p\n", catch_stack, pcs);
...
if ((fail_value = do_setjmp(pcs[catch_stack_pos])) == 0) {
Dynamic jmp_buf should allocated using aligned_alloc() function for x64.
Quote7.24.3 Memory management functions
1 The order and contiguity of storage allocated by successive calls to the aligned_alloc, calloc,
malloc, and realloc functions is unspecified. The pointer returned if the allocation succeeds is
suitably aligned so that it may be assigned to a pointer to any type of object with a fundamental
alignment requirement and size less than or equal to the size requested. It may then be used to
access such an object or an array of such objects in the space allocated (until the space is explicitly
deallocated).
#3
Bug reports / Segmentation fault with setjmp...
Last post by Thomas Mertes - May 30, 2026, 07:46:21 AMIf I compile and run the program below with gcc it writes:
In main
malloc successful
okay
Other C compilers have also no problem with this test program.
If I compile and run this test program with Pelles C it
triggers a segmentation fault after writing:
In main
malloc successful
This is the test program:
#include <stdio.h>
#include <stdlib.h>
#include <setjmp.h>
#define do_setjmp(jump_buf) setjmp(jump_buf)
typedef jmp_buf catch_type;
catch_type *catch_stack;
size_t catch_stack_pos;
size_t max_catch_stack;
int main (int argc, char **argv)
{
int fail_value;
catch_stack_pos = 0;
max_catch_stack = 128;
printf("In main\n");
fflush(stdout);
catch_stack = (catch_type *)(malloc(max_catch_stack * sizeof(catch_type)));
if (catch_stack != NULL) {
printf("malloc successful\n");
fflush(stdout);
if ((fail_value = do_setjmp(catch_stack[catch_stack_pos])) == 0) {
printf("okay\n");
fflush(stdout);
}
}
return 0;
}
In main
malloc successful
okay
Other C compilers have also no problem with this test program.
If I compile and run this test program with Pelles C it
triggers a segmentation fault after writing:
In main
malloc successful
This is the test program:
#include <stdio.h>
#include <stdlib.h>
#include <setjmp.h>
#define do_setjmp(jump_buf) setjmp(jump_buf)
typedef jmp_buf catch_type;
catch_type *catch_stack;
size_t catch_stack_pos;
size_t max_catch_stack;
int main (int argc, char **argv)
{
int fail_value;
catch_stack_pos = 0;
max_catch_stack = 128;
printf("In main\n");
fflush(stdout);
catch_stack = (catch_type *)(malloc(max_catch_stack * sizeof(catch_type)));
if (catch_stack != NULL) {
printf("malloc successful\n");
fflush(stdout);
if ((fail_value = do_setjmp(catch_stack[catch_stack_pos])) == 0) {
printf("okay\n");
fflush(stdout);
}
}
return 0;
}
#4
Bug reports / Re: Calling cc with CreateProc...
Last post by TimoVJL - May 29, 2026, 12:24:00 PMWith Windows 7 x64.
Code Select
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'. #5
Bug reports / Re: Calling cc with CreateProc...
Last post by Michele - May 29, 2026, 09:49:25 AMThank 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:
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
I made again an even simplest test from the command line. Writing the command:
Code Select
"c:\Program Files\PellesC\Bin\cc.exe" /Go "test program.c"I get the error:Code Select
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
#6
Bug reports / Re: Calling cc with CreateProc...
Last post by TimoVJL - May 29, 2026, 09:12:28 AMWhat Windows OS version was used in failed tests ?
#7
Bug reports / Re: Calling cc with CreateProc...
Last post by MrBcx - May 29, 2026, 08:16:28 AMQuote from: Thomas Mertes on May 29, 2026, 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.
#8
Bug reports / Re: Calling cc with CreateProc...
Last post by Thomas Mertes - May 29, 2026, 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
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
#9
Bug reports / Re: Calling cc with CreateProc...
Last post by John Z - May 29, 2026, 02:11:58 AMMr. 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
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
#10
Bug reports / Re: Calling cc with CreateProc...
Last post by Thomas Mertes - May 28, 2026, 11:39:32 PMSummary: 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
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