6 ms·

I guess given that it was UB before, the compiler was already allowed to put a system call here if it wanted for some reason

by saghm 14d ago

fc417fc802 14d ago
Yes, it was a horrible situation that has been replaced by an only slightly less horrible situation.
- saghm 14d ago
  I don't totally agree with this. To me, UB is an order of magnitude worse than pretty much anything else, so this is more than "slightly less" horrible. I don't necessarily disagree that this is still horrible, but I also don't write an C++, so I'm mostly just commenting as an outside observer.
chowells 14d ago
Not only that, the code was wrong. The specification is quite clear that correct programs don't cause UB to be executed at run time. If your wrong code now produces wrong results, that's because it's wrong. That your compiler allowed you to get away with it for decades is a compiler bug, not a feature. Do I fully believe all of the above? Not exactly. But compiler authors do. Does it make a really good argument to never use C or C++? Yes. If only we had 50 years of optimization work in any language with better semantics.
- saghm 14d ago
  Yeah, my slightly more verbose take is that a language that requires you to not ever make any mistakes in order to have a program behave in a predictable way is not a particularly good choice of language if you the ability to pick something else.
- JoshTriplett 14d ago
  The mistake was declaring infinite loops to be UB in the first place.
- throwaway786678 13d ago
  > That your compiler allowed you to get away with it for decades is a compiler bug That UB was added in C++11.
  - chowells 13d ago
    That sounds like 1.5 decades to me...
- TuxSH 13d ago
  FWIW while(true) / for(;;) (or any other loop condition that is a true constant-expression) is NOT UB in C, only C++. In any case stuff like __asm__ __volatile__("" ::: "memory") prevent such optimizations in the rare case you do need branch-to-self.
- classified 13d ago
  > don't cause UB to be executed at run time. The insidious thing about UB is that it doesn't necessarily have to be executed to wreck your program. UB is not primarily about runtime behavior, it's about how the compiler interprets your code. The behavior that is undefined is your compiler's behavior.
  - chowells 13d ago
    You're right. I didn't enumerate every way UB can make a program go wrong. I'm sure I don't even know every way that can happen. But "UB doesn't happen at run time" is an assumption that lots of "optimizations" are based on.
cryptonector 14d ago
Yes, but now it has to. I guess that's better? than UB, maybe.
- saghm 13d ago
  Oh, definitely agreed. It's still not great, but it's a lot better than before.

I guess given that it was UB before, the compiler was already allowed to put a system call here if it wanted for some reason

by saghm 14d ago

I guess given that it was UB before, the compiler was already allowed to put a system call here if it wanted for some reason

fc417fc802 14d ago

Yes, it was a horrible situation that has been replaced by an only slightly less horrible situation.

saghm 14d ago
I don't totally agree with this. To me, UB is an order of magnitude worse than pretty much anything else, so this is more than "slightly less" horrible. I don't necessarily disagree that this is still horrible, but I also don't write an C++, so I'm mostly just commenting as an outside observer.

chowells 14d ago

Not only that, the code was wrong. The specification is quite clear that correct programs don't cause UB to be executed at run time. If your wrong code now produces wrong results, that's because it's wrong. That your compiler allowed you to get away with it for decades is a compiler bug, not a feature. Do I fully believe all of the above? Not exactly. But compiler authors do. Does it make a really good argument to never use C or C++? Yes. If only we had 50 years of optimization work in any language with better semantics.

saghm 14d ago
Yeah, my slightly more verbose take is that a language that requires you to not ever make any mistakes in order to have a program behave in a predictable way is not a particularly good choice of language if you the ability to pick something else.
JoshTriplett 14d ago
The mistake was declaring infinite loops to be UB in the first place.
throwaway786678 13d ago
> That your compiler allowed you to get away with it for decades is a compiler bug That UB was added in C++11.
- chowells 13d ago
  That sounds like 1.5 decades to me...
TuxSH 13d ago
FWIW while(true) / for(;;) (or any other loop condition that is a true constant-expression) is NOT UB in C, only C++. In any case stuff like __asm__ __volatile__("" ::: "memory") prevent such optimizations in the rare case you do need branch-to-self.
classified 13d ago
> don't cause UB to be executed at run time. The insidious thing about UB is that it doesn't necessarily have to be executed to wreck your program. UB is not primarily about runtime behavior, it's about how the compiler interprets your code. The behavior that is undefined is your compiler's behavior.
- chowells 13d ago
  You're right. I didn't enumerate every way UB can make a program go wrong. I'm sure I don't even know every way that can happen. But "UB doesn't happen at run time" is an assumption that lots of "optimizations" are based on.

cryptonector 14d ago

Yes, but now it has to. I guess that's better? than UB, maybe.

saghm 13d ago
Oh, definitely agreed. It's still not great, but it's a lot better than before.