Why "global" variable can't be processed properly?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi!
  I have a question about "global" variable accessing when gcc compile some code. See example below:
//----------start-----------
#include <stdio.h>

int  aiArray[10];
int  iCurArrayIdx;

int GetNewValue( int iValue )
{
    //do something...

    //i change the global variable intentionally.
    iCurArrayIdx = 1;   

    //assume the return is 1
    return 1;
}

int main( int argc, char* argv[] )
{
    aiArray[iCurArrayIdx] = GetNewValue( aiArray[iCurArrayIdx] );

    printf( "aiArray[iCurArrayIdx] = %d\n", aiArray[iCurArrayIdx] );

    return 0;
}
//----------end-------------

I know the coding is very bad. It's simple for demo.

I compile these code under VC6 and GCC-4.2.4/linux and run,
then I get the differ result.

VC6 printf: aiArray[iCurArrayIdx] = 1
GCC printf: aiArray[iCurArrayIdx] = 0

I think VC6 got the correct executable content.

So I use objdump to get the assemble code of GCC output:
08048454 <_Z11GetNewValuei>:
 8048454:	55                   	push   %ebp
 8048455:	89 e5                	mov    %esp,%ebp
 8048457:	c7 05 a8 97 04 08 01 	movl   $0x1,0x80497a8
 804845e:	00 00 00 
 8048461:	b8 01 00 00 00       	mov    $0x1,%eax
 8048466:	5d                   	pop    %ebp
 8048467:	c3                   	ret    

08048468 <main>:
 8048468:	8d 4c 24 04          	lea    0x4(%esp),%ecx
 804846c:	83 e4 f0             	and    $0xfffffff0,%esp
 804846f:	ff 71 fc             	pushl  -0x4(%ecx)
 8048472:	55                   	push   %ebp
 8048473:	89 e5                	mov    %esp,%ebp
 8048475:	53                   	push   %ebx
 8048476:	51                   	push   %ecx
 8048477:	83 ec 10             	sub    $0x10,%esp
 804847a:	8b 1d a8 97 04 08    	mov    0x80497a8,%ebx
 8048480:	a1 a8 97 04 08       	mov    0x80497a8,%eax
 8048485:	8b 04 85 80 97 04 08 	mov    0x8049780(,%eax,4),%eax
 804848c:	89 04 24             	mov    %eax,(%esp)
 804848f:	e8 c0 ff ff ff       	call   8048454 <_Z11GetNewValuei>
 8048494:	89 04 9d 80 97 04 08 	mov    %eax,0x8049780(,%ebx,4)
 804849b:	a1 a8 97 04 08       	mov    0x80497a8,%eax
 80484a0:	8b 04 85 80 97 04 08 	mov    0x8049780(,%eax,4),%eax
 80484a7:	89 44 24 04          	mov    %eax,0x4(%esp)
 80484ab:	c7 04 24 90 85 04 08 	movl   $0x8048590,(%esp)
 80484b2:	e8 f5 fe ff ff       	call   80483ac <printf@plt>
 80484b7:	b8 00 00 00 00       	mov    $0x0,%eax
 80484bc:	83 c4 10             	add    $0x10,%esp
 80484bf:	59                   	pop    %ecx
 80484c0:	5b                   	pop    %ebx
 80484c1:	5d                   	pop    %ebp
 80484c2:	8d 61 fc             	lea    -0x4(%ecx),%esp
 80484c5:	c3                   	ret    
 80484c6:	90                   	nop    
 80484c7:	90                   	nop    
 80484c8:	90                   	nop    
 80484c9:	90                   	nop     
 
 Then I found the reason of run differ result:
 	Address of 804847a, iCurArrayIdx has load in EBX
 	Address of 8048494, use the old iCurArrayIdx keep in EBX and not update
 
 Puzzle! Is this GCC's bug, or feature, or standard ambiguity? Why be that?

--horde

---------------------------------------------------------------------- 
Ian reply:
The order of evaluation of the left hand side and the right hand side of
the assigment operator is unspecified in C.  Therefore, the behaviour of
this program is unspecified, because iCurArrayIdx could be retrieved
before or after GetNewValue is called, and different compilers are free
to implement this program differently.

----------------------------------------------------------------------
Thanks Ian! 
Now can any people tell me how to ensure the order of evaluation to get the expectant result alike VC6. BTW:I wouldn't like to modify the expression:
aiArray[iCurArrayIdx] = GetNewValue( aiArray[iCurArrayIdx] );

--horde







      ___________________________________________________________ 
  好玩贺卡等你发,邮箱贺卡全新上线! 
http://card.mail.cn.yahoo.com/


[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux