Linux – glibc documentation and byte order

glibc documentation and byte order… here is a solution to the problem.

glibc documentation and byte order

glibc documentation on process completion status indicates that the macro WEXITSTATUS returns the low 8 bytes of the completion status.

Macro: int WEXITSTATUS (int status)

If WIFEXITED is true of status, this macro returns the low-order 8 bits of the exit status value from the child process.

However, /usr/include/sys/wait.h says:

# define WEXITSTATUS(status)    __WEXITSTATUS (__WAIT_INT (status))

Also, /usr/include/bits/waitstatus.h mentions:

/* If WIFEXITED(STATUS), the low-order 8 bits of the status.  */
#define __WEXITSTATUS(status)   (((status) & 0xff00) >> 8)

Unless my byte-order concept is all messed up, how did this low 8 bit come about? Or does libc assume that the data is saved in a little-endian fashion?

Solution

This is not an endianness issue. Byte order refers to how data is stored in memory; On a big-endian or little-endian machine, (((status) & 0xff00) >> 8) extracts bits 15 through 8, i.e. the 8th to 15th least significant digit macro parameter of status.

Documentation and comments are confusing because states refer to two different things.

The exited process returns a status code. This exit state has a type int in the source code (either as a return value for main, or as a parameter to exit), but the value should be between 0 and 255.

The wait and waitpid system calls also return a status to the caller. This state is different; The lower 8 bits of the original exit state are now in bits 15 through 8. I’M ASSUMING THE DOCUMENTATION SAYS THAT WEXITSTATUS RETURNS “LOWER 8 BITS” BECAUSE FROM THE PERSPECTIVE OF THE EXIT PROCESS, THIS IS A PACKAGE OF EXIT STATUS

Related Problems and Solutions