On Wednesday, 1 March 2023 at 09:37:48 UTC, rempas wrote:
Thank you! You are amazing for explaining it! I was so focused
on thinking that I'm doing something wrong with the type that I
didn't noticed that the pointers, points to nowhere so the
function obviously has nowhere to write to. Like... OMG! And I
want to make a fully fledged compiler when making stupid
mistakes like that. Btw, When I executed the program, I got
"Error Program exited with code -11". You said that the code
was "11". What about that dash? If it is not a "minus" and it's
just the dash symbol, then what's the idea?
Yay!
Yes, that is a bit weird. First of all, the actual signal is 11
```
$ grep SIGSEGV /usr/include/bits -R
/usr/include/bits/signum-generic.h:#define SIGSEGV
11 /* Invalid access to storage. */
```
As per the POSIX spec
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_21_18. signal exits must be reported with exit codes above 128. Customarily, shells will simply add 128 to the signal:
```
$ cat test.c; gcc test.c -otestc; ./testc; echo $?
int main() { int* ip = 0; *ip = *ip; return 0; }
Segmentation fault
139
```
139 being 128 + 11, but POSIX does not specify *how* the signal
code is converted to an exit code. For instance, Python reports a
signal 11 exit as -11. Strictly speaking, -11 is "above 128" in
two's complement, corresponding to unsigned 245. But I don't know
why Python does this. Presumably your shell does it the same way?
