> unless exploited by an attacker
This is an enormous caveat, and it's also definitely not the only reason that you should care about it. If you want to write software that's reliable and safe, undefined behavior is a huge problem even without considering security.
Conversation
Depends how you define “problem”.
The issue is that a vocal minority of programmers see UB code as a problem. while(1); is UB before C11, but it was never a problem, except to compiler authors.
After all, how would you make a thread loop forever without calling abort()?
2
In fact, it might be impossible to formally verify both the compiler toolchain and all emitted code. Godel has a few things to say on the subject.
1
1
You're misinformed about what was changed and the impact of the change. I suggest referring to the C11 standard. It's a controversial change but isn't tied to what the standard says is undefined behavior. There's a big difference between permitted implementation choices and UB.
1
Refer to the parallel thread in this chain. There is a long discussion about it, and the consensus seems to be that infinite loops either were or are undefined behavior in some cases.
2
twitter.com/kardonice/stat
You could argue that while(1); being transformed into nothingness is well-defined. But it’s shocking for a lot of programmers. And I would be curious if any compiler actually does that in practice.
Quote Tweet
Replying to @KardOnIce @jckarter and 2 others
"[ Note: This is intended to allow compiler transfor- mations, such as removal of empty loops, even when termination cannot be proven. — end note ]"
1
This not a quote from any C standard, and certainly not C99. It's about C++11, not C11, and definitely not C99.
1
1
Yeah, completely different thread and standards being referenced. Daniel's reference C11, I'm referencing C++11, and both in very different contexts.
1
Then can we agree that since C is a subset of C++, there exist some dialects and versions of C and/or C++ where while(1); is undefined behavior?
2
C is not a subset of C++. Proof by contradiction:
test.c:
#include <stdio.h>
int main(void) {
printf("%zu\n", sizeof('a'));
return 0;
}
% clang test.c -o test && ./test
4
% clang -x c++ test.c -o test && ./test
1
2
1
4
C standards aren't entirely backwards compatible. They are mostly backwards compatible, but do make some subtle backwards incompatible changes. C++ standards make far more blatant backwards incompatible changes. Also, in particular, C99 and C11 are much further from C++ subsets.