Programming

H friends,
As we know, a function returns a value and that value is saved somwhere. like

Code:

int Sum( int x, int y )
{
return x + y;
}
 
Total = Sum( 10, 20 );

The value 30 is saved in variable Total.

Now the question is, what int value does the function main return, and where is it saved. And can we see the value of the integer returned by main.
Please explain by the help of a small program.

Thank you very much!

Moderator's Comments:

114 posts and no code tags?!...

Read the main page on waitpid or wait to get more detail.

The return value of a process to the calling is process is the least significant eight bits of the number returned by main(). Which can be seen as signed or unsigned by the parent. So, the valid results from calling wait on a child returns values from 0 to 255 (looked at as unsigned).

By convention 0 means success, as defined in C by EXIT_SUCCESS.

Since main() is an int function you can return any valid int, but is not very useful to return numbers larger than the range I just defined.

Code:

// retval.c
#include <stdio.h>
#include <stdlib.h>
int main(int argc, char **argv)
{
     int retval=atoi(argv[1]);
     printf("I am returning %d\n", retval);
     return retval;
}

Compile retval then run it with this script

Code:

#!/bin/ksh
cnt=1
while [ $cnt -le 100000000 ]
do
       retval $cnt
       cnt=$((  $cnt * 10 ))
done

And see what happens...

I think only the first 8 bits of it actually gets returned to the operating system.

Hi,

In Unix, the main function can usually return any int value as its status, which is captured by the OS. You can always see the return value of any program by simply doing echo $?

For example,

Code:

int main()
{
return 5;
}

Check it

Code:

echo $?
5

It doesnt make a lot of sense here, but when the code throws exceptions like for example dereferencing an invalid pointer, or invalid airthmetic operation (divide by 0) etc, then the OS terminates the process and the return value would describe the type of error encountered.

For e.g.

Code:

int main(int argc, char **argv)
{
char *p = 0;
*p = '4';
return 5;
}

Result

Code:

[test]$ ./a.out 
Segmentation fault (core dumped)
[test]$ echo $?
139

Hope that helps,
Regards,
Gaurav.

void exit(int status)
pid_t wait(int *stat_loc);

As already mentioned, only the low 8 bits of exit()'s int argument, status, are meaningful. The rest are practically ignored. However, it is an error to assume that the low 8 bits written by wait() to stat_loc are the low 8 of exit()'s status. This is often not the case. Since the layout of wait()'s *stat_loc bitmask is implementation dependent, POSIX specifies macros for examination and retrieval.

The 139 "exit status" in Gaurav's post isn't a true exit status. When a process exits abnormally, the bits which encode exit status have no meaningful value (which is why you are required to consult WIFEXITED() to confirm that the process exited normally before examining the exit status with WEXITSTATUS()).

If it's not an exit status, then what is it? If it wasn't an exit() argument, and if it wasn't main()'s return value, and if it's not provided by the kernel, then where does the 139 come from?

Before checking the exit status of it's child, the shell confirms that it exited normally, with WIFEXITED(). When the confirmation fails, the shell consults WIFSIGNALED(). Determining that the process was signaled and terminated abnormally, the signal number is retrieved with WTERMSIG(). By convention, the shell adds 128 to the signal number and stores that result in its ? parameter.

If your C code wait()ed on a process that was killed by that same signal, in the signal bits examined by WTERMSIG(), it would see 11 and not 139.

To avoid ambiguity, if you plan to invoke your binaries with the shell, it's a good idea to keep to exit values in the range 0 to 125 inclusive. The remaining values are spoken for: 126 (command found but not executable), 127 (command not found), and values larger than 128 (signal number + 128).

(Some of the following may be x86 specific.)

Returning to the original question: Where is the exit status stored? Inside the kernel.

When you call exit(n), the least significant 8 bits of the integer n are written to a cpu register. The kernel system call implementation will then copy it to a process-related data structure.

What if your code doesn't call exit()? The c runtime library responsible for invoking main() will call exit() (or some variant thereof) on your behalf. The return value of main(), which is passed to the c runtime in a register, is used as the argument to the exit() call.

When the parent calls wait(stat_loc), the exit status value (along with other status information) is copied from the kernel process structure to the address pointed to by wait()'s stat_loc.

Once a dead process is wait()'d on and its status information delivered, the kernel can destroy that process' data structure. Until then, the lingering data structure is the hallmark of a zombie.

Regards,
Alister

@corona -

Yes. I think I mentioned the least signficant 8 bits.

I might as well inject the whole sysexits thing here, too:

Man Page for sysexits (freebsd Section 3) - The UNIX and Linux Forums

The idea here is to use predefined exit values for various error conditions.
When you see a unix command return an error code like 64, chances are the exit codes conform to the sysexits model. sysexits is a model, or a suggestion. But it does allow the program to convey intelligence when an error occurs.

For example the diff command (by POSIX standards) has it's own little protocol. It does not use sysexits because in part the information ( or meaning ) associated with two return codes of the three are not errors.

Code:

return value    meaning
0                  differences found
1                  no differences found
2                  some other error occurred

This parallels in part alister's comment about the "range" of return values.