https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79373
--- Comment #10 from Steven Pigeon <steven.p.pigeon at gmail dot com> --- (In reply to Jonathan Wakely from comment #9) > (In reply to Steven Pigeon from comment #7) > > I do understand that this is what happens (the code is fixed by promoting > > int32_t t=x to int64_t t=x) but the undefined behavior affects a variable > > (and its associated comparison) that should not be affected by it. > > The C++ standards defines undefined behavior as "behavior for which this > International Standard imposes no requirements". No requirements. Not > "doesn't affect things that you think shouldn't be affected". All bets are > off. > > There is no requirement for a compiler to do something you find > unsurprising, or to limit the scope of the bug to parts of the code you > expect to misbehave. That's somewhat disconcerting, as some programs do rely on "expected undefined behavior". For example, val = ((state[0] * 1103515245) + 12345) & 0x7fffffff; (found in http://sourceware.org/git/?p=glibc.git;a=blob;f=stdlib/random_r.c;hb=glibc-2.15#l375 ) will overflow (because if I understand correctly, in an int times int operation, neither operands are promoted to a larger int type, and if overflow occurs, it's undefined behavior). Should that mess up the program in unpredictable ways? I'm trying to understand what exactly I'm fighting in order to avoid further problems.
