Could you point out a construct that is valid in C99 but invalid in C++?
Conversation
void func(int x) {
int [x] arr;
}
Will that do it for you?
For how about?
char* x = malloc(5);
1
1
The first one requires VLAs in C99, which are not supported in C++ (and never should have been supported in C, IMO), and the second requires an implicit void cast, which C++ requires the use of `reinterpret_cast` for, making the implicit cast explicit.
2
Part of the reason I stress the difference between C and C++ is their superficial similarity has been the source of many, many bugs.
1
I don’t know what to believe anymore. One half of the root twitter tree says infinite loops without side effects are UB. This chain makes persuasive arguments to the contrary.
What’s a decent rule of thumb regarding what to avoid in the context of loops in C/C++?
2
In C, infinite loops are well-defined. However, in the most recent C standards, it's permitted for the compiler to assume that loops terminate if they do not have a constant expression (per restrictions on those in C) as their condition and they do not have any side effects.
1
2
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.
1
1
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.
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
Show replies