Every Linux process eventually ends. There are exactly two broad categories of termination: abnormal and normal.

This part focuses on normal termination and specifically the difference between the raw system call _exit() and the C library wrapper exit().

_exit() is the raw Linux system call for process termination. It goes directly into the kernel — no userspace cleanup happens.

Key facts you must know:

• _exit() never returns — the process always terminates successfully.
• The status argument is the termination status passed to the parent process.
• Although status is declared as int, only the bottom 8 bits (0–255) are actually made available to the parent via wait().
• By convention: 0 = success, non-zero = failure.
• Values > 128 should be avoided — the shell uses 128 + signal_number to indicate signal-caused termination, and you can get confusion.
• Does NOT flush stdio buffers.
• Does NOT call atexit() handlers.
• _exit() is UNIX/POSIX specific — declared in <unistd.h>.

What _exit() skips (compared to exit()):

exit() is a C standard library function that wraps _exit() with extra userspace cleanup steps. Most programs call exit(), not _exit() directly.

Exact steps performed by exit():

When a child process exits, its parent can retrieve the termination status using wait() or waitpid() combined with the macro WEXITSTATUS().

How the status bits work:

SUSv3 (POSIX) defines two portable constants so your code communicates intent clearly. Both are defined in <stdlib.h>.

Using these constants instead of raw 0 and 1 makes code self-documenting and portable across all C platforms.

Doing return n; from main() is generally equivalent to calling exit(n) — the C runtime startup code that called main() uses the return value in a call to exit().

However there is one critical exception:

Behaviour when falling off end of main() or returning without a value:

Best practice: Always write an explicit return 0; (or return EXIT_SUCCESS;) at the end of main(), and always compile with at least -std=c99.

This program writes to stdout without a newline (so data stays in the stdio buffer), then calls either exit() or _exit() depending on a command-line argument. Redirect output to a file to clearly see the buffer flushing difference.

/* demo_exit_flush.c
 * Compile : gcc -Wall -o demo_exit_flush demo_exit_flush.c
 * Run     : ./demo_exit_flush 0 > out.txt && cat out.txt   → data appears
 *           ./demo_exit_flush 1 > out.txt && cat out.txt   → data missing!
 */
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

int main(int argc, char *argv[])
{
    /* No '\n' — data stays in stdio buffer, NOT yet written to kernel */
    printf("stdio buffered text (no newline)");

    /* write() goes straight to kernel buffer — always visible */
    write(STDOUT_FILENO, "\n[write() output is always immediate]\n", 38);

    if (argc > 1 && argv[1][0] == '1') {
        /*
         * _exit() terminates immediately.
         * stdio buffer is NEVER flushed.
         * The printf text above is LOST when output goes to a file.
         */
        _exit(EXIT_SUCCESS);
    } else {
        /*
         * exit() calls fflush() on all open streams before _exit().
         * The printf text WILL appear even without a newline.
         */
        exit(EXIT_SUCCESS);
    }
}

Demonstrates the 8-bit truncation rule. The child calls exit(-1) but the parent sees 255 — also shows EXIT_SUCCESS / EXIT_FAILURE usage.

/* demo_exit_status.c
 * Compile : gcc -Wall -o demo_exit_status demo_exit_status.c
 * Run     : ./demo_exit_status
 */
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/wait.h>

static void fork_and_check(int exit_val)
{
    pid_t pid;
    int   wstatus;

    pid = fork();
    if (pid == -1) { perror("fork"); exit(EXIT_FAILURE); }

    if (pid == 0) {
        /* CHILD */
        printf("  Child PID %d: calling exit(%d)\n", getpid(), exit_val);
        exit(exit_val);   /* only bottom 8 bits reach parent */
    }

    /* PARENT */
    if (waitpid(pid, &wstatus, 0) == -1) {
        perror("waitpid");
        exit(EXIT_FAILURE);
    }

    if (WIFEXITED(wstatus))
        printf("  Parent: WEXITSTATUS = %d\n\n", WEXITSTATUS(wstatus));
}

int main(void)
{
    printf("--- exit(0) → parent sees: ---\n");
    fork_and_check(0);          /* parent sees 0 */

    printf("--- exit(42) → parent sees: ---\n");
    fork_and_check(42);         /* parent sees 42 */

    printf("--- exit(-1) → parent sees: ---\n");
    fork_and_check(-1);         /* parent sees 255 ! (-1 & 0xFF = 0xFF = 255) */

    printf("--- exit(256) → parent sees: ---\n");
    fork_and_check(256);        /* parent sees 0 ! (256 & 0xFF = 0) */

    return EXIT_SUCCESS;
}

Shows how the exit status differs when main() has no explicit return, compiled under C89 vs C99.

/* demo_no_return.c
 * Compile C89 : gcc -std=c89 -Wall -o demo89 demo_no_return.c
 *               ./demo89 ; echo "Exit status: $?"   → random (may not be 0)
 *
 * Compile C99 : gcc -std=c99 -Wall -o demo99 demo_no_return.c
 *               ./demo99 ; echo "Exit status: $?"   → always 0
 */
#include <stdio.h>

int main(void)
{
    printf("Running with no explicit return or exit()\n");
    printf("Under C89: exit status is UNDEFINED (stack junk)\n");
    printf("Under C99: equivalent to return 0 (exit status = 0)\n");

    /* No return statement — intentionally omitted for demonstration */
}

Answer: _exit() is a direct Linux system call (declared in <unistd.h>) that immediately terminates the process. It does not flush stdio buffers and does not call atexit handlers. exit() is a C library function (declared in <stdlib.h>) that first calls all atexit/on_exit handlers in reverse order, then flushes all open stdio streams, and finally calls _exit(). Use _exit() in child processes after fork() to avoid double-flushing parent’s stdio buffers.

Answer: Only the bottom 8 bits (bits 0–7) of the status argument are made available to the parent via WEXITSTATUS(). When a child calls exit(-1), the value -1 in binary is 0xFFFFFFFF (32-bit two’s complement). Only the bottom 8 bits (0xFF = 255) are passed, so the parent sees 255, not -1. This is why exercise 25-1 in the book asks exactly this question.

Answer: The shell uses the convention that when a process is killed by a signal, $? is set to 128 + signal_number. For example, SIGINT (signal 2) gives $? = 130. If a process explicitly calls exit(130), the shell cannot distinguish whether the process was killed by SIGINT or terminated voluntarily with status 130. This causes shell script logic errors.

Answer: Usually yes, but not always. If an atexit handler or code run during exit() processing accesses local variables of main() (e.g., a local buffer passed to setvbuf()), then returning from main() causes undefined behaviour because those stack variables are destroyed. Calling exit() explicitly is safe because the local variables are still in scope.

Answer: Yes. File descriptors are closed by the kernel as part of process termination, regardless of whether _exit() or exit() is called. What _exit() skips is the userspace stdio buffer flush. Data still in the userspace stdio buffer (not yet handed to the kernel) will be lost; data already in the kernel buffer cache is safe and will be written to disk.

Answer: _exit() → #include <unistd.h> (POSIX, UNIX-specific). exit() → #include <stdlib.h> (ISO C standard, cross-platform). Including the wrong header causes implicit declaration warnings or errors. On 64-bit systems an implicit function declaration can lead to incorrect pointer-size assumptions and stack corruption.

Answer: In C89, this is undefined behaviour — the exit status is whatever value happens to be in a particular CPU register or stack location at that point. In C99 and later, falling off the end of main() is equivalent to return 0;, so the process exits with status 0. Always compile with -std=c99 or later and add an explicit return EXIT_SUCCESS; for clarity.