Bug 1073202

Created attachment 871179 [details]
worksFine.c

(In reply to Yin.JianHong from comment #1)
> Created attachment 871179 [details]
> worksFine.c

use the worksFine.c, it works fine; I'm confused,,

(In reply to Yin.JianHong from comment #0)
> How reproducible:
> always
> 
> Steps to Reproduce:
> 1. compile the .c file attached
> 2. ./a.out
> 3. echo $?
> 
> Actual results:
> # echo $?
> 92
> 
> Expected results:
> # echo $?
> 0

Both of your programs may invoke undefined behaviour.

It is valid C++ to avoid the return in main, and in that case the return defaults to 0. This doesn't seem to be what you are doing, you need to compile with g++ to have this behaviour.

It is valid C99 to avoid the return in main, defaulting in that case to returning 0 e.g. use `-std=c99'. However, the RHEL compiler doesn't default to C99, you'd need to ask it.

In general failing to call exit or use a return statement from a non-void main results in undefined behaviour, you have violated ISO C90 and any behaviour can be expected from the return of main (your programs exit code).

Sometimes putting a call to a function that returns 0 at the end of main can result in the return register being carried unmodified to the exit of main and serving as the exit code. That is extremely bad practice, undefined behaviour, and as you can see the results are unpredictable.

The correct solution is use `return 0;' at the end of main or `return close(fd)'.

So you have several options:
* Fix the code (adding -Wall warns of the problems)
* Compile as C++.
* Compile as ISO C99.

(In reply to Carlos O'Donell from comment #4)
> (In reply to Yin.JianHong from comment #0)
> > How reproducible:
> > always
> > 
> > Steps to Reproduce:
> > 1. compile the .c file attached
> > 2. ./a.out
> > 3. echo $?
> > 
> > Actual results:
> > # echo $?
> > 92
> > 
> > Expected results:
> > # echo $?
> > 0
> 
> Both of your programs may invoke undefined behaviour.
> 
> It is valid C++ to avoid the return in main, and in that case the return
> defaults to 0. This doesn't seem to be what you are doing, you need to
> compile with g++ to have this behaviour.
> 
> It is valid C99 to avoid the return in main, defaulting in that case to
> returning 0 e.g. use `-std=c99'. However, the RHEL compiler doesn't default
> to C99, you'd need to ask it.
> 
> In general failing to call exit or use a return statement from a non-void
> main results in undefined behaviour, you have violated ISO C90 and any
> behaviour can be expected from the return of main (your programs exit code).
> 
> Sometimes putting a call to a function that returns 0 at the end of main can
> result in the return register being carried unmodified to the exit of main
> and serving as the exit code. That is extremely bad practice, undefined
> behaviour, and as you can see the results are unpredictable.
> 
> The correct solution is use `return 0;' at the end of main or `return
> close(fd)'.
> 
> So you have several options:
> * Fix the code (adding -Wall warns of the problems)
> * Compile as C++.
> * Compile as ISO C99.

find a quarrel in a straw
I just curious: WHY different result between s390x and other arch.
”Platform-independent“ it can meet？

if feel no need, please close again with WONTFIX or CANTFIX;

(In reply to Yin.JianHong from comment #5)
> find a quarrel in a straw
> I just curious: WHY different result between s390x and other arch.
> ”Platform-independent“ it can meet？
> 
> if feel no need, please close again with WONTFIX or CANTFIX;

The instruction scheduling is all based on the backend s390x support, and each backend is different and schedules differently, and thus you might not have the register with a zero return (result of close) result being preserved as the function exits. The function epilogue might touch it also for use as a temporary to return the stack. You have no control over this unless you use return or exit or a standard that guarantees it. It is very very platform *dependent*.

Cheers,
Carlos.

Additional info: the same test in RHEL-6.5 it return 0;

so maybe, this is not a high priority problem,
but I think the developer should be clear why the different happen...

There is nothing we can fix here. If someone has a concrete suggestion please file a new issue with the suggestion.