3

glibc documentation on process completion status states that the macro WEXITSTATUS returns the low order 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))

And, /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 endian-ness concepts are all messed up, how is this the low-order 8 bits? Or is libc assuming that the data is kept in a small-endian way?

Community
  • 1
  • 1
Sandip Bhattacharya
  • 1,042
  • 10
  • 11

1 Answers1

4

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

The documentation and comments are confusing because status refers to two different things.

The process that exits returns a status code. This exit status has type int in the source (either as return value from main, or as argument to exit), however, the value should be between 0 and 255.

The wait and waitpid system calls also provide a status back to the caller. This status is different; the low-order 8 bits of the original exit status are now in bits 15 through 8. I assume the documentation says WEXITSTATUS returns the "low-order 8 bits" because that was the packing of the exit status from the perspective of the exiting process.

Andy
  • 4,789
  • 23
  • 20
  • The documentation says "low order 8 bits" because, although the child process can have any `int` return value, in a Posix environment, only the least significant 8 bits of that status are returned to the parent. http://pubs.opengroup.org/onlinepubs/009695399/functions/_exit.html – JeremyP May 10 '11 at 11:11