#include<stdio.h> main() { static int a[20]; int i=0; a=i++; printf("%d %d %d",a[0],a[1],i); } output : 0 0 1 My question is while incrementing i at a=i++; In output i value is 1 ,then why a[0] value is not incremented wont the output be 1 0 1
a=i++; this is undefined behavior... the answer may change from compiler to compiler...try running the code on different compiler.. this is technically a sequence point...just go through the link and you will understand it better.. http://c-faq.com/expr/seqpoints.html
In the statement a= i++; a[0]=0 then i will increase to 1 . Now what will be a[1] to a[19] ???? It's value will be zero as normal array. Now it does not matter what's value of i. i.e. Means a[1]=a[2]=a[3] .......=a[19]= 0; Rules of Array: If First element is initilized to any value then all next to this element will have zero value. Example: int a[20]; a[2]=12; Then values of a[0], a[1] will be Garbage. a[2] will be 12. and a[3] to a[19] will be ZERO.
This program is running in GNU compiler(g++ & gcc). Only it depends On Array Implementation in compiler. As geven answer by me is tested on Solaris machine using gcc compiler.
hi asadullah.ansari.. there is no such rule...i have written a small code .. Code: int main( void ) { int var[12]; var[2] = 0; printf("%d%d",var[2], var[3] ); return 0; } this code compiles with a warning in Visual Studio and crashed when run.. and this code compiles with no warning using cc in Red Hat and gives garbage value for x[3] and not 0.. the rule/standard is that if an array has been declared/defined as a static array then all its variable are initialized to zero.. and about Code: a[i] = i++ i am sure it is a sequence point ..as explained clearly in the link given by me in the earlier post . i believe that even you were talking about the case when variable are declared/defined as static.
I think technosavvy's got this one nailed down > Only it depends On Array Implementation in compiler. There lies the problem. When you have an answer which doesn't work for everyone, it's a sure sign of implementation specific, unspecified or even undefined behaviour. Remember, undefined always includes doing what you expected (or perhaps wanted). This is even more true in small test case programs where it's all to easy to see behaviour which seems entirely plausible, but it is in fact specific to the compiler. For example, one could routinely get away with uninitialised pointers in small DOS programs, but scale up to a larger program and sooner or later, the mistake is exposed.
