On Thu, 2021-04-22 at 11:28 -0500, Peng Yu wrote: > On 4/22/21, Xi Ruoyao via Gcc-help <gcc-help@xxxxxxxxxxx> wrote: > > On Wed, 2021-04-21 at 21:40 +0200, Stefan Ring wrote: > > > On Wed, Apr 21, 2021 at 8:41 PM Xi Ruoyao via Gcc-help > > > <gcc-help@xxxxxxxxxxx> wrote: > > > > > > > > I sincerely don't like to see someone try to "learn" by running > > > > some > > > > program containing "i = i++ + i++" and "inspect" the output. > > > > > > Nothing wrong with that! I did almost exactly this in the early > > > nineties on DOS, with 16-bit Borland C++ ;) > > > > > > But now I see what you're getting at. I understand the > > > assembly/machine code as output. But you were probably talking about > > > the result of the calculation. > > > > Well, even the asm/machine code can't be relied on. As it is an UB > > the > > compiler can output some really strange thing, maybe: > > What original C code cause the compile to generate these different > assembly code snippets? They seem to come from different C code unless > you are taking about optimization for the same C code. If it is the > latter, then it seems the optimization is not done properly in some of > the cases. I don't understand what point you want to prove here. "i = i++ + i++" invokes undefined behavior. The standard has no requirement. The compiler can do anything. I mean you can't learn to program (at least in C) just by doing experiments here and there and trying to parse some result out of it. And your reaction proved my point, again: after so many strange experiments you still don't even know undefined behavior. > > Maybe the only "meaningful output" is: > > > > > test.c:6:4: warning: operation on 'i' may be undefined [-Wsequence- > > > point] > > > > (I think you absolutely understand what I posted above, but I'll still > > post it to warn new learners :) Stefan: you see that? The post is really necessary :(. -- Xi Ruoyao <xry111@xxxxxxxxxxxxxxxx> School of Aerospace Science and Technology, Xidian University
