I am pretty sure it's possible to merge these to programs into one that shows GCC is as wrong as Clang on this.
No because the original program has UB (by overflowing stack). C std actually omits this but it's obvious.
-
-
Overflowing the stack isn't undefined though. Compilers can and should be handling it sanely like MSVC++.
-
SO is undefined, by contradiction if nothing else. C doesn't preclude unlim rec, but imposes finite # objs
-
There is an obvious limit on the # of objects if you take their addresses. Otherwise it's more tricky.
-
Allowing pgm w/ >2**CHAR_BIT*sizeof(void*) objs violates req that objs have addr even w/out &, by cnt arg.
-
Objects are not required to have an address, they could be located in registers.
End of conversation
New conversation -
-
-
I don't think you can label it as UB that easy. Whether something UB or not is decided based on the std alone and\
-
I label SO as UB because the standard leaves it undefined by omission of any attempt to resolve contradictions around it.
-
Well, the standard doesn't mention stack at all. One way to look at it is that, hence, there are no restrictions on\
-
a program related to stack. Thus, all implementation using stack are not conforming.
-
But as you mentioned memory is limited in practice, stack or not. And there are similar problems with static vars.
-
You can ignore the word "stack". Problem is that the C std ignores inherent finitude of automatic storage.
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.