------- Comment #3 from tim dot bruylants at vub dot ac dot be 2007-08-31 19:05 ------- Can someone please explain me why this behavior is correct according to the specifications? Isn't the function call issuing a new sequence point? Isn't the ++(*p_a); statement in the function a separate sequence point? Isn't the return a sequence point?
>From what I can see is that the statement: "(*p_a) += inca_and_ret1(p_a);" is evaluated in an undefined order. That's ok. No problems there. Except that the (*p_a) is evaluated by already taking the value at that memory location and caching it somewhere, then calling the function, and then performing the math on the cached value, thus skipping the increment inside the function. It feels to me that it is a bug and that it is caused by internal caching of values rather than undefined evaluation order (which indeed is allowed). And besides the discussion on this being correct behaviour or not, these kind of issues make some compilers (like GCC-4) a real pain to use safely. I know the example here is straight forward and that it is plain easy to see that this is not the best code, but I bumped into this with a much less obvious construction (involving a struct variable). Wouldn't at least a warning be a nice thing to generate in such cases? Don't get me wrong, I'm not trying to start the discussion about evaluation order all over. I just think this has nothing to do with that. I hope someone cares enough to explain this case to me and why GCC is correct (or not).(In reply to comment #1) > > *** This bug has been marked as a duplicate of 11751 *** > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33270
