I think it's very clear that this was a change in semantics, but the scope of the change is very small. It also says nothing about infinite recursion. The C standard glosses over how functions are supposed to work and C implementations essentially need an infinitely large stack.
Conversation
Clearly, they cannot actually have one, but the C standard does not allow undefined behavior on infinite recursion. In practice, it's going to overflow the stack, but it's not permitted to optimize it out as LLVM does in some cases due to an implementation bug. It's not allowed.
1
1
It's also not permitted to let the stack overflow go undetected and clobber other things in memory. It's not explicitly required to detect it, but any sane implementation should reliably detect it and abort safely. Clang can't do that outside Windows. It's only safe on Windows.
1
The semantics adopted in C++11 and later for optimization assumptions about infinite loops and the semantics in previous standards don't match C. I don't know the C++ standard well enough to say much about how it works there. I do know how it works in C quite well though.
1
1
It's not permitted to do what LLVM is doing for infinite recursion and LLVM is doing it across all C standards + other languages, because it's a bug, similar to Clang's lack of stack probes outside Windows which is not just a bug but a serious exploitable security vulnerability.
1
LLVM has an optimization bug in the removal of unnecessary calls to pure functions. Infinite recursion is one way to see that bug, but so are infinite loops. C11 does not permit removing the infinite loop `while (1) { ... }`. Consider this example:
1
1
3
3
2
3
Yep, working exactly like the C++11 standard would allow it to, which is a pretty major bug IMO for C.
1
It's an even bigger bug for languages like Rust because it breaches memory safety. People can also run into it while trying to use ! to make their code type check by using `loop {}` as a to prove to the compiler that the function doesn't return to avoid unsafe for unreachable().
1
2
Yet, if your code actually hits that case, instead of infinite looping it can fall through to what should be an impossible program state per the semantics of the language because the compiler removed the call to the function. This allows breaching memory safety in safe Rust.
However, Rust code isn't untrusted, so unsoundness like this isn't a security vulnerability. It can definitely become a security vulnerability, but while I think it's likely that people are going to hit this in practice, I don't think it's likely it will ship as a security bug.
1
1
2
On the other hand, (crazy) people use LLVM to implement a VMs with sandbox semantics. So bugs like this can definitely be exploited by attackers. In this case, LLVM explicitly chose to keep the buggy optimization rather than removing it until it's fixed. Don't use LLVM like that.
1
1
Show replies