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

[Brian Budge <brian dot budge at gmail dot com>]

You have to modify iCurArrayIdx after the statement, or perform the
assignment in the function call.

2009/4/27 Robin.Horde <robinhorde@yahoo.com.cn>:
>
> 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/
>