Your favourite C++ undefined behaviours?

[rajroshi]

@moorecm

Thanx for clearing it a bit more for me I am definitely learning from you guys.

Now again which subexpression will evaluate first is undefined, ok, agree. But it is not going to change final result you can check all the cases above and you can evaluate as you want, just keep 2 things in mind precedence and postfix will yield the original value.

I am not saying anyone is wrong, just want to clear my doubt I am able to calculate the result after that my GNU GCC and visual studio compiler are also giving the same result. So please give some example, I could understand it a bit better.
All the case above are pretty clear and I don't think any compiler will give different result because you can evaluate either one first answer will be the same.

Like 4th case

int x=0;
int z=--x + x--;

now we will take --x first ok x= -1, now second x-- , x is still -1
so z=-1 + -1 = -2;

So how it is goona change the result. if we evaluate --x first or x--.

Thanx again.

[helios]

now we will take --x first ok x= -1, now second x-- , x is still -1
so z=-1 + -1 = -2;

NO.

So how it is goona change the result. if we evaluate --x first or x--.

This hypothetical compiler does pre-{in|de}crement as soon as possible, and post-{in|de}crement whenever.
If --x is evaluated first:

//x=10;
--x;
temp=x;
temp+=x;
x--;
//temp=18 

If x-- is evaluated first:

//x=10
--x;
temp=x;
x--;
temp+=x;
//temp=17 

[Duthomhas]

Helios, I think these two are more interested in quibbling and trying to prove their brains are really smart than straight-forward understanding.

By "undefined behavior" is meant exactly what it says. The behavior is not defined.

behavior

3. The manner in which something functions or operates

http://www.answers.com/main/ntquery?q=behavior&afid=5052&s=behavior&search=

undefined

Not precisely ... determined

http://www.answers.com/main/ntquery?q=undefined&afid=5052&s=undefined&search=

All of programming is interested in behavior. For programming to be effective, the behavior must be defined. If it is not, then it is not possible to program.

Efforts spent trying to determine the behavior of something that is, by explicit definition, undefined, is a waste of time.
http://www.parashift.com/c++-faq-lite/misc-technical-issues.html#faq-39.15

Here is more reading, which you could have found easily enough.
http://en.wikipedia.org/wiki/Undefined_behavior
http://www.devx.com/tips/Tip/12684

Note: Your brains are not big enough to armchair philosophize this into a box. Programming works by definition -- not any one person's powers of reason and discovery, however [un]advanced it may be.

[rajroshi]

@helios

Good post I have got it now.

Thanx for your help to clear my doubt.

@Duoas

Sorry to disturb you, please try to cope with "undefined behavior" of human.

[Duthomhas]

LOL, well put.
Sorry I was grouchy.
(My sugar must have been low or something.)

[KarlisRepsons]

Duoas, about easy finding: google has taken me through awful lengths of redundancy, so was I asking someone, who wrote he knows.
If I had to guess about 'sugar or something', I'd say either you simply hate someone trying to guess the behaviour when it's not defined or this thread took more time than you like.

Initially I expected people to post some ugly lines of code, which they know, but I guess, they are too ugly to even post in significant quantities :)

[Duthomhas]

Neither. All serious programming languages work by being defined... so except for that little thing in C and C++ there isn't much you can write in the way of a valid program that produces "undefined behavior".

[KarlisRepsons]

I came back to post what's in my file "undefined behaviour" as examples:

*] char* ch = "asdasda"; ch[0] = 'a';

*] int v2[10]; int* p2 = v2 - 2; int v2[10]; int* p2 = v2 - 2; *p2; /*or*/ *p2 = 21;

*] int *p1, *p2; p1 - p2; int v1[10]; int v2[10]; int i2=&v1[5]-&v2[3];

*] f(i, i++), ...

*] conversions from floating point type
to integer type, "when there's no representation"
are undefined

*] conversion double -> float, if
sizeof(float) < sizeof(double)

*] (x++ + ++x), (x++ + x), (x-- + x), (++x + x), (--x + x--), ...

[helios]

char* ch = "asdasda"; ch[0] = 'a';

Technically, the undefined behavior starts in the first statement. There's an implicit cast that eliminates constness.

int v2[10]; int* p2 = v2 - 2;

int *p1, *p2; p1 - p2;

Not undefined behavior.

[KarlisRepsons]

helios, about the last two: well, then undefined what? Probably you can turn up Stroustrup's "The C++ Programming Language" (3rd ed.) p 93 at the bottom and there you can see result called as "undefined".

[moorecm]

If you cite a book, consider mentioning the section not just the page so that people with different editions can check it out. ;)

[helios]

Well, your second snippet is completely different to that.

int v2[10];
int* p2 = v2 - 2;

I think Stroustrup made a small mistake here. What the text says is correct.

One can add an integer to a pointer or subtract an integer from a pointer; in both cases, the result is a pointer value. If that value does not point to an element of the same array as the original pointer or one beyond, the result of using that value is undefined.

That is, the value of p2 itself is defined. What's undefined is what happens if you later try to do this:
*p2=/*...*/;

int *p1, *p2;
p1 - p2;

The second line is a no-op. The result of the expression is undefined, but since it's not used by the program, the behavior of the program remains defined.
This is not the same as what Stroustrup wrote:

int v1[10];
int v2[10];
//...
int i2=&v1[5]-&v2[3]; //result of expression changes program state 

[KarlisRepsons]

So these can cause undefined behaviour?

int v1[10]; int v2[10]; int i2=&v1[5]-&v2[3];
int v2[10]; int* p2 = v2 - 2; *p2; /*or*/ *p2 = 21;

what about int f(int* i1, int* i2) {return i1 - i2;}?

[helios]

The behavior of f() depends on what the caller passed as parameters.

[KarlisRepsons]

Someone made a lot longer list of undef. behaviours here:
http://stackoverflow.com/questions/367633/what-are-all-the-common-undefined-behaviour-that-a-c-programmer-should-know-abo

well, if anyone feel interested...

[helios]

Recursively re-entering a function during the initialization of its static objects

It's... beautiful!