I wonder if this is correct behavior. I was surprised to get this result when compiling and running the following C code with Apple clang version 14.0.0 (clang-1400.0.29.102) target arm64-apple-darwin21.6.0 on a M1 Pro 12.7.6 with cc -O2 file.c:
#include <stdio.h>
#include <stdlib.h>
unsigned long long factorial(int n)
{
unsigned long long fac = 1;
while (n > 0)
fac *= n;
return fac;
}
int main()
{
return factorial(1);
}
Compiling with -O2 and running this code gives "Trace/BPT trap".
Checking with LLDB:
$ lldb ./a.out
(lldb) target create "./a.out"
Current executable set to '/Users/engelen/Projects/Euler/a.out' (arm64).
(lldb) run
Process 79580 launched: '/Users/engelen/Projects/Euler/a.out' (arm64)
Process 79580 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BREAKPOINT (code=1, subcode=0x100003fb4)
frame #0: 0x0000000100003fb4 a.out`main at 20.c:9:3 [opt]
6 unsigned long long fac = 1;
7 while (n > 0)
8 fac *= n;
-> 9 return fac;
10 }
11
12 int main()
The loop is non-terminating. But a breakpoint trap is triggered at the return statement. The code should just hang in the loop IMO, not trap, because it never updates variable n (a correct factorial function should decrement n). Never seen this before (not since I started wiring C code in the 80s.)
If I change the update *=
into +=
then there is no trap.