-1

I was looking for some area of C,where we get different behaviors by different compilers.

Looking to following code,We get output 7 in gcc4.4.5, and 10 in tcc4.5.

int i=0;
i=i++ + ++i + i++ + ++i;
printf("%d",i);

Can we identify other area of usage where we get different behaviors, which should be avoided for a good programming practice.

[Note: Above specified code is just an example. The question does not stick only to this.]

  • 3
    You want us to give you every example of undefined behavior, and then you want us to show you why exactly the compiler designer chose (or as the result of a side effect) as certain implementation? Then this has nothing to do with C, and you should go look at the source code for gcc – Falmarri Feb 11 '11 at 06:23
  • 2
    The current C Standard has [26 pages dedicated to listing portability issues like this](http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf) (all of Annex J). To find out a specific compiler's behavior, you must consult its documentation. There are many, many C compilers. This question is vague and overly broad and thus should be closed as not a real question. – James McNellis Feb 11 '11 at 06:28
  • @Falmarri, I wanted to discuss the area of undefined behavior, after knowing which one can avoid using it in practice. –  Feb 11 '11 at 06:29
  • possible duplicate of [Could anyone explain these undefined behaviors (i = i++ + ++i , i = i++, etc...)](http://stackoverflow.com/questions/949433/could-anyone-explain-these-undefined-behaviors-i-i-i-i-i-etc) – Suma Feb 11 '11 at 06:34
  • Following may be of interest to you as well: http://stackoverflow.com/questions/2397984/undefined-unspecified-and-implementation-defined-behavior – Suma Feb 11 '11 at 06:38
  • @moderators, pl remove the question. –  Feb 12 '11 at 04:58

3 Answers3

4

The result is "compiler dependent" because it is undefined behavior as far as the language is concerned.

Except where noted, the order of evaluation of operands of individual operators and subexpressions of individual expressions, and the order in which side effects take place, is unspecified. Between the previous and next sequence point a scalar object shall have its stored value modified at most once by the evaluation of an expression. Furthermore, the prior value shall be accessed only to determine the value to be stored. The requirements of this paragraph shall be met for each allowable ordering of the subexpressions of a full expression; otherwise the behavior is undefined.

Ed S.
  • 122,712
  • 22
  • 185
  • 265
  • 1
    Cant we predict behavior for a particular compiler(version specified) and the side-effects? –  Feb 11 '11 at 06:27
  • @ramshankar: Only by looking at the source code. – Falmarri Feb 11 '11 at 06:35
  • 1
    Yes, but why in the world would you want to? There is no good reason to rely on undefined behavior. – Ed S. Feb 11 '11 at 07:05
  • @ramshankar Indeed, why would you want to? You already said this sort of thing should be avoided, and you're right. And we don't need a list here -- it's already spelled out in the C standard. – Jim Balter Feb 11 '11 at 07:50
  • @jim balter, I didnt expect some where all these are listed in one place, anyway nice to know as some pointed out the sources like C standard. –  Feb 11 '11 at 07:57
0

the particular example you cited, i ++ + ++i, is explicitly undefined according to K&R. there is a list of other undefined expressions.

Foo Bah
  • 25,660
  • 5
  • 55
  • 79
0

As Ed pointed out the C++ spec leaves some things undefined - another example would be the evaluation order of parameters. You may get "compiler specific" behaviour, but you're more likely to get something more random (as some of these undefined areas are to make optimisation easier). Is this just out of interest, or are you trying to do something strange?

user611942
  • 135
  • 1
  • 10
  • 1
    The order in which arguments are evaluated is not _undefined_; it is _unspecified_. The two terms have very different meanings; you can find their definitions in clause 3 of C99, to which I linked in a comment to the original post. – James McNellis Feb 11 '11 at 06:32