Conversation

Replying to

and

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

Status Quo

@KardOnIce

Aug 1, 2019

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 ]"

Replying to

and

This not a quote from any C standard, and certainly not C99. It's about C++11, not C11, and definitely not C99.

Replying to

and

Yeah, completely different thread and standards being referenced. Daniel's reference C11, I'm referencing C++11, and both in very different contexts.

Replying to

and

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?

Replying to

and

C is absolutely not a subset of C++. Anyone who claims such either does not know C or does not know C++, full stop.

Replying to

and

Could you point out a construct that is valid in C99 but invalid in C++?

Replying to

and

void func(int x) { int [x] arr; } Will that do it for you? For how about? char* x = malloc(5);

Replying to

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.

Replying to

Part of the reason I stress the difference between C and C++ is their superficial similarity has been the source of many, many bugs.

Replying to

and

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++?

Replying to

and

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.

11:15 PM · Aug 1, 2019Twitter Web App

Replying to

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.

Replying to

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.

Show replies