> x = some_operation_on(x) + 10; > Is it undefined too?
It is not undefined as the function call is a sequence point. On Thu, Aug 18, 2011 at 12:00 AM, Amahdy <[email protected]> wrote: > 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. > -- 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.
