Please see my response below, -- Amahdy www.amahdy.net
On Wed, Aug 17, 2011 at 14:25, Baris Acar <[email protected]> wrote: > Maybe you are correct here, it's neither a bug nor as designed, it's just > undefined, which means that other behavior could be taken under different > machines, and thus different results. > > > A concern is that, while your analysis is interesting, you may risk > misleading learners when you engage in discussion of this without peppering > it with caveats and warnings; I'd suggest a large, bold disclaimer at the > top rather than a footnote at the end, to indicate that the behaviour you > are describing is not mandated by any standard and could be different in any > of these situations (and more): > - with other compilers > - with other versions of GCC > - with the _same_ version of GCC on other OSes > - with the same version of GCC with different optimisations turned on > - with the same GCC, optimisations and OS on a different computer > I totally agree with you on everything said till here. > - with the same GCC, optimisations, OS and even computer, run twice in a > row on the same computer. > - with the same _compiled binary_, run twice on the same computer. > - randomly > - on Tuesdays > - when there is a full moon > I don't agree on this part, the compiler behavior is not random, so its operation at the end of the day must be fixed, and once determined it will be the same. What I mean is that, the compiler follow some logical procedures that's, even if undefined, won't change under the same software and hardware combined (unless you are requesting to, like using the rand functions). > > This variability of the behaviour seems to be completely permitted by the > standard. The practical upshot of this is that as a programmer you should > never rely on such behaviour (I think a good compiler can warn you if you > do). > > There is a good treatment of this topic on Stack Overflow: > <http://stackoverflow.com/questions/340282/c-mystery><http://stackoverflow.com/questions/340282/c-mystery> > http://stackoverflow.com/questions/340282/c-mystery - in particular > answers by phihag and Michael Burr, who both point out the specific > section of the standard that says that the behaviour is undefined (the > latter explains what "undefined" means). I agree with Michael's sentiment: > > "I think trying to explain what the compiler is doing... is not > particularly helpful, as that misses the point. The compiler could be doing > almost anything; in fact, it's likely that the compiler may reach a > different result when it's run using differing optimization options (or may > produce code that crashes - who knows?)." > The compiler must be explained at some point to determine weather its processing is correct or not, nobody bother about undefined processing is another topic but it must have an explanation at some point. For example, someone said "*modifying a variable twice in a single expression has no defined behavior*", what about the following: x = some_operation_on(x) + 10; > Is it undefined too? -- Amahdy www.amahdy.net > > Barış > > On 16 Aug 2011, at 23:00, Amahdy < > <[email protected]><[email protected]><[email protected]><[email protected]> > [email protected]> wrote: > > k=++j + (++j + ++j); it gives 15! >> > > As explained before, here is the compiler behavior that lead to this > output: > > j=2 > Divide the long expression into two branches: ++j AND (++j + ++j) > > The first branch: j=j+1, then the result is found in j > The second branch: divide into two subbranches, ++j AND ++j > > The first branch: j=3 and its result is found in j > The second branch: > The first subbranch: j=j+1, then the result is found in j > The second subbranch: j=j+1, then the result is found in j > > The first branch: j=3 and its result is found in j > The second branch: > The first subbranch: j=4 and its result is found in j > The second subbranch: j=5 and its result is found in j > > The first branch: j=5 > The second branch: Add(The first subbranch: {j=5} , The second > subbranch:{j=5}), which gives 10 > > *The result:* Add(The first branch: {j=5}, 10), which gives 15 > > > > I agree, and the 'deep language specification' here is that this >> behaviour is undefined. >> > > Maybe you are correct here, it's neither a bug nor as designed, it's just > undefined, which means that other behavior could be taken under different > machines, and thus different results. > > > -- Amahdy > <http://www.amahdy.net> <http://www.amahdy.net> > <http://www.amahdy.net><http://www.amahdy.net><http://www.amahdy.net> > www.amahdy.net > > > > On Tue, Aug 16, 2011 at 12:09, Paul Smith < > <[email protected]><[email protected]><[email protected]><[email protected]><[email protected]> > [email protected]> wrote: > >> On Tue, Aug 16, 2011 at 1:03 AM, Amahdy < >> <[email protected]><[email protected]><[email protected]><[email protected]><[email protected]> >> [email protected]> wrote: >> > I don't agree with you +Paul, one of the essential learning curves IMHO, >> is >> > to learn the compiler behavior and the deep language specifications and >> > details. >> >> I agree, and the 'deep language specification' here is that this >> behaviour is undefined. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "google-codejam" group. >> To post to this group, send email to >> <[email protected]><[email protected]><[email protected]><[email protected]><[email protected]> >> [email protected]. >> To unsubscribe from this group, send email to >> <google-code%[email protected]><[email protected]><[email protected]><[email protected]><[email protected]> >> [email protected]. >> For more options, visit this group at >> <http://groups.google.com/group/google-code?hl=en><http://groups.google.com/group/google-code?hl=en><http://groups.google.com/group/google-code?hl=en><http://groups.google.com/group/google-code?hl=en><http://groups.google.com/group/google-code?hl=en> >> http://groups.google.com/group/google-code?hl=en. >> >> > -- > You received this message because you are subscribed to the Google Groups > "google-codejam" group. > To post to this group, send email to > <[email protected]><[email protected]><[email protected]><[email protected]> > [email protected]. > To unsubscribe from this group, send email to > <[email protected]><[email protected]><[email protected]><[email protected]> > [email protected]. > For more options, visit this group at > <http://groups.google.com/group/google-code?hl=en><http://groups.google.com/group/google-code?hl=en><http://groups.google.com/group/google-code?hl=en><http://groups.google.com/group/google-code?hl=en> > http://groups.google.com/group/google-code?hl=en. > > -- > You received this message because you are subscribed to the Google Groups > "google-codejam" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/google-code?hl=en. > -- You received this message because you are subscribed to the Google Groups "google-codejam" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-code?hl=en.
