Introduction to Processes

A process is an executing program. It has a memory address space, a program image, handles to files, and the operating system state needed for interprocess communication.

Every process has a parent. In traditional UNIX systems, the top of the process tree is init. On Windows, several system processes fill similar roles, including system.exe for the kernel, csrss.exe for user-mode Win32 support, wininit.exe for system services, explorer.exe for the shell, and winlogin.exe for login services.

Process Memory Layout

A process address space is normally divided into a few major regions. The text segment contains the machine instructions of the program. The data segment contains initialized static data and constants. The BSS segment contains uninitialized static data.

The heap is used for dynamic memory allocation. A process may have one or more heaps. The stack contains local variables, call frames, and return values. Kernel-mode threads normally have one stack per thread. User-mode threading libraries may multiplex many user threads over a smaller number of kernel-thread stacks.

The loader is responsible for laying out the text, data, BSS, initial heap, and initial stack. After the process starts, stack and heap management are handled by the program, its runtime library, and the operating system.

Process Memory Layout

Memory Layout

Multithreaded Memory Layout

Memory Layout for Multithreaded Programs

Preliminaries

The code examples are maintained at gkthiruvathukal/systems-code-examples. You can use git clone https://github.com/gkthiruvathukal/systems-code-examples to clone them into a folder named systems-code-examples.

Full working demonstrations are referenced by directory name, such as systems-code-examples/fork. To build most examples, install gcc, cmake, and make. The examples have been tested on Ubuntu Linux, macOS, and Windows Subsystem for Linux 2 with Ubuntu.

Most examples use the same pattern:

$ cd systems-code-examples/<example-name>
$ cmake .
$ make

The output executable is normally written to the example’s bin subdirectory.

Examine Process Layout Example

The systems-code-examples/c_intro example is a small C++ program used to examine process layout and the basic build process. It is also a useful first example because it has separate source files and a CMake build.

Get and build the code:

$ git clone https://github.com/SoftwareSystemsLaboratory/systems-code-examples
$ cd systems-code-examples/c_intro
$ cmake .
$ make

Run the layout shell script to show the size of the text, data, and BSS sections in bytes:

$ ./layout

section               size   addr
.text                 3957    4352
.data                   24   20480
.bss                     8   20504

The main program for this example is:

#include "list.hh"
#include "debug.hh"
#include "tests.hh"
#include <stdio.h>

int main(int argc, char *argv[])
{
    int passCount = runTests();

    printf("%d tests passed\n", passCount);

    return 0;
}

Key points:

• The program is split across multiple source files, so the build has to compile each file and link the resulting object files.

• The example gives us an executable we can inspect with tools such as size and nm.

• The layout script connects the compiled program back to the text, data, and BSS sections discussed above.

Loading Programs

When a program is loaded, the loader allocates memory for the executable text, data, BSS, heap, and stack. It then loads the program image into memory.

The loader also handles shared libraries. It asks the operating system which shared libraries are already loaded and loads the ones that are not. Each shared library has its own text, data, and BSS sections. The loader then resolves external symbols so references in the executable point to the correct locations in memory.

The nm command shows symbols in a compiled object file or executable. After the executable is ready, the loader invokes _start(). _start() calls _init() for each shared library, initializes static constructors for global objects, and then calls main().

Simple Executable Example

The systems-code-examples/hello-exe example is the smallest complete executable example in the repository. It is useful for confirming the build process before looking at larger programs.

#include "hello.h"

int main(int argc, char** argv)
{
    say_hi("George");
}

Key points:

• main() is the entry point that application programmers normally write, even though the loader starts execution before main().

• The program calls a function from a header-defined interface rather than doing all work inline.

• This is a minimal executable for checking compiler, linker, and loader behavior.

Loading shared libraries (.so)

Libraries also have text, data, and BSS sections. Shared libraries must use position-independent memory references so the same library can be mapped at different addresses in different processes. GCC uses the -fpic or -fPIC flags for this. Newer GCC versions often make PIC the default. Use -fno-pic when you need to compare against non-PIC output.

The dynamic linker resolves position-independent memory accesses by writing entries in the global offset table, or GOT, for each process. This is necessary because a shared library may be loaded at different offsets in different executions, while still allowing the operating system to share the library’s text segment among processes.

Shared Library Example

The systems-code-examples/hello-lib example separates a function into a small library and calls it from an executable. This is the simplest repository example for discussing the boundary between application code and library code.

#include <stdio.h>
#include "hello.h"

void say_hi(char* person)
{
    printf("Hello, %s\n", person);
}

#ifndef _HELLO_H_

#define _HELLO_H_

extern void say_hi(char* person);

#endif

Key points:

• hello.h declares the interface that other source files can include.

• hello.c provides the implementation that can be compiled into a library.

• The executable depends on the library code being linked or loaded before the call to say_hi() can run.

more about GCC pic option

Based on the man page for gcc:

Generate position-independent code (PIC) suitable for use in a shared library, if supported for the target machine. Such code accesses all constant addresses through a global offset table (GOT). The dynamic loader resolves the GOT entries when the program starts. If the GOT size for the linked executable exceeds a machine-specific maximum size, the linker reports that -fpic does not work. In that case, recompile with -fPIC instead.

Loading static libraries

Static libraries do not contain position-independent code. A static library is a collection of unlinked .o object files. When the program is linked, the linker copies the needed object code into the final executable.

Position Independent Code Example

The systems-code-examples/pic example shows the difference between generating PIC and non-PIC assembly.

Get the code and build it with the example makefile:

$ git clone https://github.com/SoftwareSystemsLaboratory/systems-code-examples
$ cd systems-code-examples/pic
$ make -f Makefile.pic

main.c

#include <unistd.h>

const char *msg = "abcdefg";

int main(int argc, char* argv[])
{

    const char *x = msg + 1;

    write(1, x, 1);

    return (0);

}

main.nopic.s - non-position independent code (gcc -fno-pic)

	.file	"main.c"
	.text
	.globl	msg
	.section	.rodata
.LC0:
	.string	"abcdefg"
	.data
	.align 8
	.type	msg, @object
	.size	msg, 8
msg:
	.quad	.LC0
	.text
	.globl	main
	.type	main, @function
main:
.LFB0:
	.cfi_startproc
	endbr64
	pushq	%rbp
	.cfi_def_cfa_offset 16
	.cfi_offset 6, -16
	movq	%rsp, %rbp
	.cfi_def_cfa_register 6
	subq	$32, %rsp
	movl	%edi, -20(%rbp)
	movq	%rsi, -32(%rbp)
	movq	msg(%rip), %rax
	addq	$1, %rax
	movq	%rax, -8(%rbp)
	movq	-8(%rbp), %rax
	movl	$1, %edx
	movq	%rax, %rsi
	movl	$1, %edi
	call	write
	movl	$0, %eax
	leave
	.cfi_def_cfa 7, 8
	ret

main.nopic.s - position independent code (gcc -fpic, default option)

	.file	"main.c"
	.text
	.globl	msg
	.section	.rodata
.LC0:
	.string	"abcdefg"
	.section	.data.rel.local,"aw"
	.align 8
	.type	msg, @object
	.size	msg, 8
msg:
	.quad	.LC0
	.text
	.globl	main
	.type	main, @function
main:
.LFB0:
	.cfi_startproc
	endbr64
	pushq	%rbp
	.cfi_def_cfa_offset 16
	.cfi_offset 6, -16
	movq	%rsp, %rbp
	.cfi_def_cfa_register 6
	subq	$32, %rsp
	movl	%edi, -20(%rbp)
	movq	%rsi, -32(%rbp)
	movq	msg@GOTPCREL(%rip), %rax
	movq	(%rax), %rax
	addq	$1, %rax
	movq	%rax, -8(%rbp)
	movq	-8(%rbp), %rax
	movl	$1, %edx
	movq	%rax, %rsi
	movl	$1, %edi
	call	write@PLT
	movl	$0, %eax
	leave
	.cfi_def_cfa 7, 8
	ret

What’s the difference?

diff main.pic.s main.nopic.s
7c7
< 	.section	.data.rel.local,"aw"
---
> 	.data
28,29c28
< 	movq	msg@GOTPCREL(%rip), %rax
< 	movq	(%rax), %rax
---
> 	movq	msg(%rip), %rax
36c35
< 	call	write@PLT
---
> 	call	write

Key points:

• The C source is intentionally small so the assembly differences are easier to see.

• The non-PIC version can use more direct addressing because it assumes a fixed relationship between code and data.

• The PIC version uses relative addressing through the global offset table so the code can be loaded at different virtual addresses.

Shared Libraries - Evaluation

Shared libraries reduce memory use when multiple processes load the same library because the text segment can be reused. They also allow programs to benefit from library updates without rebuilding the executable.

The cost is complexity. Shared libraries require virtual memory support, dynamic linking, position-independent code, and careful handling of version and path compatibility.

Static Libraries - Evaluation

Static libraries make sense when reuse is not important, when deployment must avoid runtime dependencies, or when the program must be self contained. Static linking can also avoid version and path problems.

The main cost is memory use. Common code is copied into each executable, so there is less sharing across processes.

Libraries vs. Statically-Linked Programs

Dynamic linking is usually chosen for memory footprint, code reuse, smaller executables, and easier library updates. Static linking is useful when deployment simplicity matters more than sharing. It can also make whole-program optimization and obfuscation easier because more code is available to the linker at once.

Process Protection

Modern operating systems use virtual memory and privilege separation to protect processes from each other and from the kernel.

One process cannot read another process’s memory unless the operating system explicitly permits it. A process can manage the memory it owns, including allocation, deallocation, garbage collection, calling conventions, and stack management. A crash, exception, resource starvation, or deadlock in one process does not directly modify another process. Even though kernel memory may be mapped into the process address space, user code cannot modify kernel memory or other protected pages.

Process Creation with fork()

fork() creates a new process by duplicating the calling process. The new process is the child. The calling process is the parent. The child has its own process ID, and its parent process ID is the parent’s process ID. The parent’s threads are not recreated in the child.

In Linux, the C library implementation of fork() uses clone(). From the programmer’s point of view, fork() returns the child PID to the parent, returns 0 to the child, and returns -1 if the child cannot be created.

fork() example

The systems-code-examples/fork example shows the basic return-value pattern used to distinguish parent and child execution.

$ cd systems-code-examples/fork
$ cmake .
$ make

#include <stdio.h>
#include <unistd.h>
#include <fcntl.h>
#include <string.h>

int main(int argc, char* argv[])
{
    int SomeValue = 100;
    int pid = fork();
    int fd = open("test_file", O_WRONLY|O_CREAT|O_TRUNC, 0666);

    const char *parentMessage = "1111111";
    const char *childMessage =  "22222222222222\n";

    if(pid > 0)
    {
        printf("hello from the parent process, chid pid = %d\n", pid);
        sleep(2);
        printf("parent's SomeValue = %d\n", SomeValue);
        write(fd, parentMessage, strlen(parentMessage) * sizeof(char));
    }
    else if(pid == 0)
    {
        printf("hello from the child process\n");
        SomeValue = 200;
        printf("child's SomeValue = %d\n", SomeValue);
        write(fd, childMessage, strlen(childMessage) * sizeof(char));
    }
    else
    {
        printf("fork() failed!!\n");
    }

    close(fd);

    return 0;
}

Key points:

• The call to fork() creates two processes that continue from the same point in the program.

• The parent sees the child’s process ID as the return value.

• The child sees 0 as the return value, which is how the code chooses the child branch.

fork() and exec() example

The systems-code-examples/fork_exec example creates a pipe, forks, redirects standard input and standard output with dup2(), and then uses execvp() to replace each process image. The parent runs wc. The child runs echo.

#include <stdio.h>
#include <unistd.h>
#include <fcntl.h>
#include <stdlib.h>

int main(int argc, char* argv[])
{

    int pipes[2];
    pipe(pipes);

    int inputPartOfPipe = pipes[0];
    int outputPartOfPipe = pipes[1];

    int pid = fork();

    if(pid > 0)  	//parent process
    {
        dup2(inputPartOfPipe, 0); // redirect STDIN
        close(outputPartOfPipe);  // close unused half of pipe

        char *wcArgs[] = {"-l", NULL};
        execvp("wc", wcArgs);

        fprintf(stderr, "should not be able to reach here!\n");
    }
    else if(pid == 0)  	//child process
    {
        dup2(outputPartOfPipe, 1); // redirect STDOUT
        close(inputPartOfPipe);     // close unused half of pipe

        char *echoArgs[] = {"-ne", "\"hello\\nworld\\n\"\n", NULL};
        execvp("echo", echoArgs);

        fprintf(stderr, "should not be able to reach here!\n");
    }
    else
    {
        printf("fork failed!\n");
    }

    //don't worry about closing remaining pipes,
    //process exit does this for us

    return 0;
}

Key points:

• pipe() creates a kernel buffer with one file descriptor for reading and one for writing.

• dup2() redirects standard input or standard output before the process image is replaced.

• execvp() replaces the current program with another executable; code after a successful execvp() call does not run.

Process Creation with clone()

clone() is similar to fork() because it creates a child execution context. Unlike fork(), it allows selected parts of the parent process to be shared with the child.

Linux uses flags to control what is shared. CLONE_FS shares file system information such as chroot, chdir, and umask. CLONE_FILES shares the file descriptor table. CLONE_SIGHAND shares signal handlers. CLONE_VM shares the page table. These flags are part of how Linux creates lightweight processes and kernel threads.

glibc’s fork() calls clone() without these sharing flags. clone() is Linux-specific and is not present in every UNIX-like operating system.

Windows CreateProcess() and CreateThread()

Windows does not expose the same process-sharing model as UNIX fork() and Linux clone(). CreateProcess() creates a new process and is closest to calling fork() followed by execve() on UNIX. CreateThread() creates a new thread and is closest to using clone() with thread-sharing flags.

For most programs, this is not a practical disadvantage. Most UNIX uses of fork() are followed by exec(), and most uses of clone() are for thread creation.

Emulating fork() on Windows

Cygwin implements fork() on Windows by combining CreateProcess(), saved register state, copied memory regions, and synchronization. The parent creates a suspended child process, saves register state with setjmp(), copies the BSS and data sections to the child, wakes the child, and then coordinates stack, heap, and memory-mapped region copies.

This approach is closer to “copy on fork” than modern UNIX copy-on-write. It is useful for compatibility, but it is more expensive than a native UNIX fork() implementation.

System Call Boundary Example

The systems-code-examples/syscall example compares three ways to write output: the C library printf(), the POSIX write() wrapper, and a direct syscall() invocation.

#include <stdio.h>
#include <string.h>
#include <unistd.h>
#include <sys/syscall.h>

int main(int argc, char* argv[])
{
    char* hello_with_syscall = "Hello World with syscall\n";
    char* hello_without_syscall = "Hello World without syscall\n";
    char* hello_with_printf = "Hello World with printf\n";

    write( 1, hello_without_syscall, strlen( hello_without_syscall ));

    syscall( SYS_write, 1, hello_with_syscall, strlen( hello_with_syscall ));

    printf( "%s", hello_with_printf );

    return 0;
}

Key points:

• printf() is a C library call, not a direct system call.

• write() is the usual POSIX wrapper for the kernel’s write system call.

• syscall(SYS_write, ...) bypasses the wrapper and invokes the system call interface directly.

Command-Line Option Example

The systems-code-examples/getopt example shows how a process receives command-line arguments through argc and argv and turns them into structured options.

#include "cl.h"

int main(int argc, char *argv[])
{

    my_options_t* options = my_program_options_get(argc, argv);
    if (options->success)
    {
        print_options(options);
        exit(EXIT_SUCCESS);
    }
    else
    {
        exit(EXIT_FAILURE);
    }
}

#ifndef _CL_H_
#define _CL_H_

#include <ctype.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <regex.h>

typedef struct my_options_t
{
    int how_many;
    int last_n_words;
    int min_length;
    int every_steps;
    int ignore_case;
    int success;
    int print_options;
    int do_timing;
    regex_t regex;

} my_options_t;

extern my_options_t *my_program_options_new();
extern void my_mrogram_options_delete(my_options_t *options);
extern my_options_t* my_program_options_get (int argc, char **argv);
extern void print_options(my_options_t *options);

#endif

Key points:

• argc and argv are the process’s command-line interface.

• The parsing code converts raw strings into a structured options object.

• The program exits with success or failure depending on whether the command line was valid.

Process Termination

A process can terminate normally by returning from main(). It can also terminate with an error code, by encountering a fatal error, or by being terminated externally by another process.

Fatal errors include segmentation faults or bus errors from invalid memory access, stack overflow, protection faults from privileged instructions, and instruction faults such as divide by zero.

wait() and waitpid() examples

The systems-code-examples/wait example shows how a parent process can wait for a child process to terminate.

#include <sys/types.h>
#include <sys/wait.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>


int main(int argc, char* argv[])
{
    pid_t pid = fork();
    if(pid == 0)
    {
        abort();    //child process exits
    }
    int status;
    wait(&status); // wait for child to exit
    if(WIFEXITED(status))
    {
        printf("normal exit. exit code = %d\n", WEXITSTATUS(status));
    }
    else if(WIFSIGNALED(status))
    {
        printf("abnormal termination, signal number = %d\n", WTERMSIG(status));
    }
    else if(WIFSTOPPED(status))
    {
        printf("child stopped, signal number = %d\n", WSTOPSIG(status));
    }
}

Key points:

• The parent process uses wait() or waitpid() to collect child exit status.

• Waiting also prevents terminated children from remaining as zombie processes.

• The status value encodes how the child terminated.

SIGCHLD examples

The systems-code-examples/fork_sigchld example handles SIGCHLD to notice when a child process exits. It uses wait() in the signal handler to collect the child’s exit status.

#include <stdio.h>
#include <string.h>
#include <signal.h>
#include <unistd.h>
#include <sys/wait.h>
#include <sys/types.h>

int child_exit_status = (-5);

void clean_up_child_process(int signal_number)
{
    printf("SIGCHLD recieved.\n");
    int status;
    wait(&status);
    child_exit_status = status;
}

void parent()
{
    printf("parent continuing....");
    while(child_exit_status == (-5))
    {
        printf("parent waiting...\n");
        sleep(1);
    }
    printf("child exit status = %d\n", child_exit_status);
    printf("parent exiting\n");
}

void child()
{
    printf("child starting.\n");
    sleep(5);
    printf("child exiting.\n");
}

int main(int argc, char** argv)
{

    struct sigaction sigchld_action;
    memset (&sigchld_action, 0, sizeof (struct sigaction));
    sigchld_action.sa_handler = &clean_up_child_process;
    sigaction (SIGCHLD, &sigchld_action, NULL);

    if(fork() > 0)
    {
        parent();
    }
    else
    {
        child();
    }

    return 0;
}

Key points:

• sigaction() installs a handler for SIGCHLD before the fork.

• The kernel sends SIGCHLD to the parent when the child exits.

• The handler calls wait() to collect the child’s exit status.

The systems-code-examples/fork_sigchld2 example extends this pattern to multiple child processes. It uses waitpid() with WNOHANG so the handler can collect every child that has exited without blocking.

#include <stdio.h>
#include <string.h>
#include <signal.h>
#include <unistd.h>
#include <sys/wait.h>
#include <sys/types.h>

#define MAX_PID (1000)

int childProcesses[MAX_PID];

void addProcess(int childPid)
{
    printf("add(%d)\n", childPid);
    for(int i = 0; i < MAX_PID; i++)
    {
        if(childProcesses[i] == (-1))
        {
            childProcesses[i] = childPid;
            printf("added child pid = %d\n", childPid);
            return;
        }
    }
}

void removeProcess(int childPid)
{
    printf("remove(%d)\n", childPid);
    for(int i = 0; i < MAX_PID; i++)
    {
        if(childProcesses[i] == childPid)
        {
            childProcesses[i] = (-1);
            printf("removed child pid = %d\n", childPid);
        }
    }
}

int countProcesses()
{
    int count = 0;
    for(int i = 0; i < MAX_PID; i++)
    {
        if(childProcesses[i] >= 0)
        {
            count += 1;
        }
    }
    return count;
}

void clean_up_child_process(int signal_number)
{
    printf("SIGCHLD recieved.\n");
    int status;
    pid_t pid;
    while((pid = waitpid(-1, &status, WNOHANG)) > 0)
    {
        if(pid > 0)
        {
            printf("pid %d exited\n", pid);
            removeProcess((int)pid);
        }
    }
    return;
}

void parent()
{
    printf("parent continuing....\n");
    while(countProcesses() > 0) { }
    printf("parent exiting\n");
}

void child()
{
    printf("child starting.\n");
    sleep(5);
    printf("child exiting.\n");
}

int main(int argc, char** argv)
{
    for(int i = 0; i < MAX_PID; i++)
    {
        childProcesses[i] = (-1);
    }

    struct sigaction sigchld_action;
    memset (&sigchld_action, 0, sizeof (struct sigaction));
    sigchld_action.sa_handler = &clean_up_child_process;
    sigaction (SIGCHLD, &sigchld_action, NULL);

    for(int i = 0; i < 5; i++)
    {
        int childProcess = fork();
        if(childProcess == 0)
        {
            child();
            return 0;
        }
        else if(childProcess > 0)
        {
            addProcess(childProcess);
        }
        else
        {
            printf("fork failed\n");
        }
    }
    parent();

    return 0;
}

Key points:

• The parent tracks child process IDs in a small table.

• The signal handler loops with waitpid(-1, ..., WNOHANG) to collect all children that have exited.

• WNOHANG matters because a signal handler should not block waiting for children that are still running.

Process-Oriented C Case Studies

Some examples in the repository are best treated as short systems C case studies. They support the process chapter because they make memory, calling conventions, and low-level representation concrete.

The systems-code-examples/objects example shows object-style programming in C using struct values and functions.

#include <stdio.h>
#include <string.h>
#include <stdlib.h>

typedef struct
{
    char Name[30];
    int Age;
    int NumberOfTeamMates;
    struct Employee** TeamMates;
} Employee;

Employee* Employee_New(char* name, const int age)
{
    Employee* newEmp = (Employee*)calloc(1, sizeof(Employee));
    memcpy(newEmp->Name, name, strlen(name)+1);
    newEmp->Age = age;
    newEmp->TeamMates = NULL;
    newEmp->NumberOfTeamMates = 0;
    return newEmp;
}

void Employee_Print(Employee* employee)
{
    printf("Name: %s\n", employee->Name);
    printf("Age:  %d\n", employee->Age);
    printf("Number of TeamMates: %d\n", employee->NumberOfTeamMates);
    if(employee->NumberOfTeamMates > 0)
    {
        printf("\t");
    }
    for(int i = 0; i < employee->NumberOfTeamMates; i++)
    {
        Employee* teamMate = (Employee*) employee->TeamMates[i];
        printf("%s, ", teamMate->Name);
    }
    printf("\n");
}

void Employee_AddTeamMate(Employee* employee, Employee* teamMate)
{
    employee->NumberOfTeamMates += 1;
    employee->TeamMates = (struct Employee**)realloc(
                              employee->TeamMates,
                              sizeof(Employee*) * employee->NumberOfTeamMates);
    employee->TeamMates[employee->NumberOfTeamMates-1] = (struct Employee *)teamMate;
}

int main(int argc, char* argv[])
{
    Employee *joe = Employee_New("Joe", 29);
    Employee *tom = Employee_New("Tom", 32);
    Employee *bill = Employee_New("Bill", 35);

    Employee_Print(joe);

    Employee_AddTeamMate(joe, tom);
    Employee_AddTeamMate(joe, bill);

    Employee_Print(joe);

    return 0;
}

Key points:

• The Employee structure groups related fields in one allocation.

• Functions such as Employee_New and Employee_Print act like methods by taking an Employee* argument.

• The example uses dynamic allocation, so it also previews memory management issues handled later.

The systems-code-examples/strlen example is a small C string and memory-layout demonstration.

#include <stdio.h>

int my_strlen(const char *str)
{
    int length = 0;
    while(*str != 0)
    {
        str++;
        length++;
    }
    return length;
}


int main(int argc, char* argv[])
{

    const char *str = "hello world";

    int len = my_strlen(str);

    printf("%d\n", len);

    return 0;
}

Key points:

• C strings are byte arrays terminated by '\0'.

• strlen() counts characters before the terminator, not the storage used by the array.

• The example is useful for connecting string behavior to memory layout.

The systems-code-examples/parity example is a low-level bit manipulation example.

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <sys/stat.h>
#include <sys/types.h>
#include <fcntl.h>

size_t parityWrite(
    int fd0, int fd1, int fd2,
    const void *buf0, const void *buf1,
    size_t count)
{
    for(size_t i = 0; i < count; i++)
    {
        char byte0 = ((char*)buf0)[i];
        char byte1 = ((char*)buf1)[i];
        char parity = byte0 ^ byte1;
        write(fd0, &byte0, sizeof(char));
        write(fd1, &byte1, sizeof(char));
        write(fd2, &parity, sizeof(char));
    }
    return count;
}

size_t parityRead(int fd0, int fd1, void *buf, size_t count)
{
    char *buff0 = (char*)malloc(count);
    char *buff1 = (char*)malloc(count);
    char *buff = (char*)buf;
    read(fd0, buff0, count);
    read(fd1, buff1, count);
    for(size_t i = 0; i < count; i++)
    {
        buff[i] = buff0[i] ^ buff1[i];
    }
    return count;
}

int main(int argc, char** argv)
{
    int fd0 = open("f0", O_CREAT|O_TRUNC|O_RDWR, 0666);
    int fd1 = open("f1", O_CREAT|O_TRUNC|O_RDWR, 0666);
    int fd2 = open("f2", O_CREAT|O_TRUNC|O_RDWR, 0666);

    const char* msg0 = "hello world\n";
    const char* msg1 = "testing 123\n";

    parityWrite(fd0,fd1,fd2,msg0,msg1,strlen(msg0)+1);

    close(fd0);
    close(fd1);
    close(fd2);

    unlink("f1");

    fd0 = open("f0", O_RDWR, 0666);
    fd2 = open("f2", O_RDWR, 0666);

    size_t msgSize = sizeof(char)*strlen(msg0)+1;
    char *buff = (char*)malloc(msgSize);

    parityRead(fd0, fd2, buff, msgSize);

    printf("f1 contents are = %s\n", buff);

    close(fd0);
    close(fd2);

    free(buff);

    unlink("f0");
    unlink("f2");

    return 0;
}

Key points:

• The code works directly with integer bits rather than higher-level data structures.

• Bit operations are common in operating systems code for flags, masks, and packed state.

• Small examples like this help make machine representation visible.