Example:

After i start the program the "zid" var. get 10 value in array.
Result:
ZID[0]=0
ZID[1]=1
ZID[2]=2
ZID[3]=3
...
...

After that i stop the program and comment this row //zid[i]=i;
And start program again.

And i get the value in the array????
Result:
ZID[0]=0
ZID[1]=1
ZID[2]=2
ZID[3]=3
....
...

How is this possible??

It is possible because no where in the second program did you set the values in the array to anything other than what was already in it.
C does not automatically zero out an array for you.
Old robotC might have, and maybe it still should, in which case it is a bug, but C does not and it is probably a good habit to get used to always initializing data as you expect it and not depending on the compiler, unless it is very specific about such.

Take a look at memset(pToBuffer, nValue, nNumbOfBytes);

The description reads "This is a useful function for initializing the value of an array to all zeros."

Spiked3 thanks for answer.
I don't need zeros in my array.
The problem is that each time I re-start the program in its array have the same values ​​that I previously enrolled in the array. So it does not happen in a normal c.
Why are the values ​​in the array is not initialized by the type of the variable, regardless of whether they are zero or something else?
This looks to me more like a variable after stopping the program has not died.
Greetings.

No, Mike is right, C does not automatically initialize the values in arrays (unless they're defined as global or static). When an array is declared, a block of memory is simply allocated, and the elements of the array will contain whatever was in that memory space before. If you have not zeroed out the array, it will contain the same values. I don't exactly how ROBOTC handles this either, but it is always good practice to initialize your arrays in C.

ROBOTC will zero out global variables at program runtime, but will not clear out local/stack variables.

Since before 3.5, all variables were "scope limited globals", everything way typically zero'd out. This is no longer the case.

I would suggest that you use memset if you wish to zero out your array without having to manually specify an initialization value.

Also, just want to eliminate the obvious... Did you recompile and download the code after you change it? You didn't say in your original post.

A programming language could act the way you describe, and many do, however C being a very old language that was one small step above assembler language, usually does not, and as just explained, RobotC does not. There is no death to a variable, like there would be in C# or Java, and actually even in those languages the variables are cleared when the memory they use is allocated to something new, not when the program ends (and this creates a huge security risk that is often exploited on other computers). I would not even depend on recompiling and downloading to behave the same way each time as I have seen cases where it did not.

Just as a side funny; we used to power off and on computers real quick and download a program to graphically display what was in memory. It made for some neat, often repeatable patterns - the good old days.

I have not been writing compilers for a long time, but as I recall, initialization of variables is implementation specific that you should not count on one way or the other. Having said that, the array variable in your main is considered local variable. Local variables are allocated on the stack (at least on most platforms and I believe in most recent RobotC too). Stack variables are not initialized unless you did it explicitly in the code. So what you saw was expected.

Thanks for the question, yes I did compile and download the program

No matter what I do agree with all the above.
I think you did not understand me, and if so, please disregard this message.
If you write the following code:

Compile and download the program to the NXT. After the program start, program stop. Okay?
After that restate the above code in the following code:

And now again:
Compile and download the program to the NXT. After the program start, program stop after 10 seconds. (To see the screen).
I see on my screen next thing.
'I' = 100
My question is: WHY 100.
And this is not strange to you?

If I have the following C program:

Run the program. After that I rewrite:

I see on my screen next thing.
'I' = -858993460

This is not strange for me, I do not know about you?
I hope I managed to describe what's in this story weird.

Greetings.

No, it is not strange to me at all. When you compile and download a new program to the NXT, it does not zero all the RAM memory in the NXT. So whatever the previous program left behind is still intact. Let's say when you loaded and ran the first program, RobotC assigned variable 'i' to memory location 1000 and variable 'a' to memory location 1004. Since you initialized variable 'a' to 100, memory location 1004 contained the value 100. Now when you compiled and downloaded the second program to the NXT, RobotC may assign the variable 'i' to location 1004. Since memory location 1004 did not get erased and it had the value 100 in it from before, now you printed the value 100. The point is, when a new program is loaded, you cannot count on where the location of a certain variable is at even though it has the same name as the previous program. So any uninitialized local variables will have "unpredictable values" in them.

I assume you ran the above C program on a Windows PC. If so, Windows PC is quite different from NXT. I don't think RobotC supports virtual memory, but Windows does. So every time you run a new program, Windows allocates different physical memory pages for your program. So even if both variable 'a' in program 1 and variable 'i' in program 2 are assigned the same virtual address (e.g. 1004), they are still on different physical memory pages. So, you will truly see garbage. I am not going too deep into it because it involves how the memory manager in Windows manages physical memory and virtual memory space. There is no way for one Windows program to leave something behind in memory for the next Windows program to retrieve. If it had been possible, it would have been a huge security hole. Imagine a virus can scan through memory and find what the previous program has left behind. There may be a password in it. In fact, Windows runs programs in their own virtual memory space. So one program can never see the memory of the other program, period. But for RobotC in NXT, security is not a concern so there is no reason to zero memory between loading different programs. I hope it doesn't confuse you more