"Go" undefined behavior with respect to C

Undefined behavior with respect to C

Transferred from: http://www.guokr.com/blog/471312/

For beginners of C, being asked to do the following question is really a brain residue can not be brain-crippled behavior. But a lot of C beginner's--actually all have this kind of problem.
The most typical example of this is

A+ =a+ +;   

In this case, how much is a finally equal?

How should the compiler understand a+=a++? The first is to unfold, a=a+a++;
Then calculate the values of a and a++, add them together, and assign the result to a.
But here is the problem, that is, after executing a++, the value of a++ is equal to the value of a itself, but the value of a is changed to a+1.
So the key is the processing order.

For example, int a=3;
If the compiler first calculates the assignment number + = The value of the left a is 3, then calculates the value of the right a++ to 3, and a becomes 4.
Then calculate the 3+3=6, assign to a, then a is now the value of 6.
If the compiler first calculates the a++ to the right of the assignment number, the result is 3, and a becomes 4, and then the left a=4 is computed.
Then the 4+3=7 is calculated, and the 7 is assigned to a.

That is to say, different ways of understanding, in this example, actually get a different answer?

Why should I use it? Isn't that an incredible result? The same expression, but the compiler is not the same, it came to different results, this is really a tragedy ah.
Are there no standards that require the compiler to adopt the same understanding pattern? The C language standard complies with the ANSI C standard. Unfortunately, in the ANSI C standard, there is no provision on how to deal with this situation, but it is pointed out that the compiler you look at it.
This is the "undefined behavior" of the C language.

In other words, I just have a gcd function of the time by a great god of the hard spit, the GCD function is as follows:

GCD(a,b(ab;}        

As the above analysis, this program in the compilation process, the order of what will appear, which is not specified in the standard, is not defined behavior.
So using this function does not necessarily guarantee that the correct result will be obtained.

This kind of thing ... Since it was given to the compiler.
I think this should actually be for code optimization. As we all know, C is a very focused on efficiency of the language, and the kind to give up all the sense of efficiency, do not evaluate this good, anyway, people in the most popular language leaderboard sat on the first throne did not know how many years.
For greater freedom to the compiler, the compiler is better able to optimize the generated binary code.
There are other aspects, such as cross-border arrays.
Just like this.

STR1[]="MyWorld";  STR1[]='           + ';

Array str1 Where's the 19th item AH!!! This stuff can actually be compiled by!!!
Using an out-of-bounds array is also an "undefined behavior" of C. The C standard does not specify what the compiler should do in this situation. This time the idea of the compiler should be--more than one thing, I do not check whether this is the range of this array, anyway, you asked me to write, I will write it.

A typical operation is to allow the reading and writing of a pointer that is casually referred to.
For example, I applied for a dynamic area and then released it:

Int*P;P=(Int*)Malloc (4*sizeof (/* various operations on p */free (p[0]=0; Printf ( "%d%d%d%d" ,p[ 0],p[1],< span class= "n" >p[2],p[ 3);              

It is no exaggeration to say that my own program died in this place many times, that is free after the print ...
Another example:

int *p;p=0x1e642a80;p[8]=24;

This kind of pointer operation actually also to pass????

What's more, these are all "undefined behaviors" in C, which means that although these operations can be done, the compiler does not guarantee the execution of the results.
So this kind of thing not only does not give an error to pass, but also does not follow the way we imagined, but by the compiler's temperament casually come?

From this point of view, it is really too hard to force.
I also ran into a piece of brain code that looks something like this:

Tips[]="No";  If(conditionstrcpy(tips,"Yes");}        

For this kind of thing ..... Oh. Running under Windows is waiting to be interrupted.
The use of uninitialized variables is also an "undefined behavior", such as:

int x;printf ("%d", x);

Usually you don't know what you're going to see on the screen ....
GCC's first version of the compiler in this case, you will start a small game on your screen. (This is the development team full of malicious AH!! Well, it must be!! ）
C's variables are not initialized at the time of declaration (or before the first use), a feature that has been criticised.
However, ANSI C itself is definitely trying to improve a bit of speed by omitting these initialization operations.
After all, it's quite laborious to initialize a large array or a lot of space allocated by malloc ...

But the advantage is ...
Does not check the array bounds, does not check the case where the pointer is pointing to the address, and does not check whether coercion of type conversions is possible. By the programmer's self-awareness, this makes C code efficiency will become very high.

So, C, although a lot of applications need program security, but because of the existence of "undefined behavior"--c is definitely not a safe language!!

But more than that, the reason for this is that it would be more desirable to use C.

One more thing to note is that:
The beginning of the paragraph:

int a=3;a+=a++;

Almost all modern compilers have the result of 7.

That GCD's line algorithm, almost all modern compilers can run normally.
Although it is an "undefined algorithm", this is also a silent agreement reached a bar.
Although, it is still dangerous to use them.

This article is published by The Flying Fish Authorization (shell net), the copyright of the article is the original author.

"Go" undefined behavior with respect to C