A short on-ramp that re-establishes the language and, just as importantly, the way you will build and run code all semester. It assumes prior C exposure and moves quickly from "what does this statement do" to "how do I compile and organise a real project".

By the end of this module you can

• Read and reason about basic C: types, expressions, control flow and functions.
• Drive the course toolchain end-to-end: terminal, Conda env, CMake build, VSCode.
• Compile a multi-file project with add_executable / add_library.

• 1
  Course Overview & General C Language Review

  Presents the general contents of the course and runs a fast refresh of C language basics and environment setup.

  • Syllabus & course goals — modules, assessment weights, the AI policy.
  • C fundamentals refresh: types, expressions, control flow — int/char/double, operators & precedence, if/while/for.
  • Functions & the shape of a C program — declarations vs definitions, main(), headers.
  • Environment setup — compiler, editor and project layout.

  Core concept — translation unit: a C program is a set of .c files each compiled to an object file, then linked into one executable; the compiler sees one translation unit at a time, which is why declarations in headers matter.

  Key idea  C is small but unforgiving: there is no runtime safety net, so you reason explicitly about types, memory and undefined behaviour from day one.

  demo: variable tracing demo: expressions demo: loops K&R ch. 1–3 — tutorial intro, types & operators, control flow
• 2
  Tooling

  The development toolchain and intended workflow for the course.

  • The terminal — navigating, running builds and binaries by hand.
  • Conda for dependencies — isolated, reproducible environments per project.
  • CMake intro and compiling — add_executable, add_library, configure-then-build.
  • Workflow — navigate via terminal → activate/create conda env → open VSCode → run cmake.
  • VSCode refresher · GitHub Education / Copilot in VS Code

  Core concept — out-of-source build: CMake reads CMakeLists.txt and generates build files in a separate build/ directory, keeping generated artefacts out of your source tree.

  Key idea  A repeatable build is part of the program: if a teammate can cmake and run your code in one command, integration during the group project is painless.

  PCP — compiler & toolchain workflow

Before going deeper into the language, the course establishes how to keep code correct: detecting and reporting errors deliberately, asserting invariants, and proving behaviour with automated tests rather than ad-hoc printf debugging.

By the end of this module you can

• Choose between return-code, errno and assertion strategies for reporting failures.
• Guard invariants with assert() and understand how NDEBUG disables them.
• Write and run unit tests with GTest and wire them into a CMake build.

• 3
  Error Handling and Assertions · subtopic 1/3

  Error handling techniques and assertions in C, while refreshing debugging techniques.

  • Error handling strategies — return codes, sentinel values, errno + perror.
  • Assertions — assert(cond) aborts when an invariant is violated.
  • Debugging techniques refresh — breakpoints, stepping, inspecting variables in a debugger.

  Core concept — contracts vs errors: an assert documents a condition the programmer believes is always true (a bug if false), whereas error handling deals with expected runtime failures such as a missing file.

  Key idea  Assertions catch your mistakes during development; error handling deals with the world's failures at runtime — they are not interchangeable.

  PCP — debugging & defensive programming
• 4
  Unit Testing · subtopic 2/3

  Writing and running automated tests for C code.

  • Unit testing principles — isolate a unit, arrange–act–assert, test edge cases.
  • GTest — TEST(Suite, Name) macros and EXPECT_*/ASSERT_* checks.
  • Setting up tests in CMake — register tests so ctest can run them.

  Core concept — regression safety: a unit test pins down expected behaviour so that a future change which breaks it fails loudly instead of silently.

  Key idea  Tests are the executable specification of your functions; once wired into CMake/ctest they turn "I think it works" into "the build proves it".

  GTest · CMake · ctest

The conceptual core of the course. Pointers, the heap and aggregate types are what let C model real data structures and manage memory by hand — the foundation every later module (linked lists, threads, socket buffers) builds on.

By the end of this module you can

• Declare, dereference and do arithmetic with pointers, relating them to memory addresses.
• Allocate and free heap memory with malloc/calloc/realloc/free without leaking.
• Model related data with struct and overlapping data with union.

• 5
  Pointers · subtopic 1/3

  Refresh the concept of pointers, their purpose, and their relationship with memory addresses.

  • Pointer declaration & initialization — int *p = &x; holds the address of x.
  • Referencing & dereferencing — & takes an address, * reads/writes the value there.
  • Pointer arithmetic — p + 1 advances by sizeof(*p) bytes; the array/pointer duality.

  Core concept — a pointer is a typed address: its value is a memory location and its type says how many bytes to read and how to interpret them, which is why char* and int* step differently.

  Key idea  Pass-by-pointer lets a function modify the caller's data and lets you share large objects without copying — the mechanism behind output parameters and every dynamic data structure.

  demo: pointers & memory K&R ch. 5 — pointers & arrays
• 6
  Dynamic Memory Allocation & Memory Management · subtopic 2/3

  Allocating and deallocating memory at runtime for flexible, efficient memory management.

  • malloc / calloc / realloc / free — request, zero-init, resize and release heap blocks.
  • Runtime allocation & deallocation — sizing buffers when the size is unknown at compile time.
  • Memory bugs — leaks, double-free, use-after-free, dangling pointers.

  Core concept — stack vs heap: locals live on the stack and vanish when a function returns; malloc returns heap memory that lives until you free it, so every allocation needs an owner responsible for releasing it.

  Key idea  In C, lifetime is your job: pair every malloc with exactly one free, and always check the returned pointer for NULL before using it.

  demo: pointers & memory K&R §7.8, §8.7 — storage allocation
• 7
  Structures and Unions · subtopic 3/3

  Structures and unions as data constructs that organize and manipulate related data elements.

  • struct definition & member access — s.field on a value, p->field through a pointer.
  • Unions — members share one block of memory; only one is valid at a time.
  • Memory layout — padding & alignment affect sizeof(struct).
  • Intro to data-oriented programming — organising data for cache-friendly access.

  Core concept — struct vs union: a struct lays its members out side by side (total size = sum + padding); a union overlaps them (size = the largest member), trading safety for compact, reinterpretable storage.

  Key idea  Structs let you name and pass aggregates as first-class values; combined with pointers they are the building block of every node-based data structure later in the course.

  demo: structs & memory layout K&R ch. 6 — structures

How a C program talks to the outside world through files, and how the preprocessor shapes the source before it is compiled. The first midterm sits inside this module, consolidating everything from modules 0–2.

By the end of this module you can

• Open, read, write and close files with the FILE* stream API, handling errors and releasing resources.
• Use preprocessor directives (#include, #define, conditional compilation, include guards).
• Write safe function-like macros and know when an inline function or constant is better.

• 8
  File Input/Output · subtopic 1/3

  Reading from and writing to files, with proper error handling and resource management.

  • Input/Output — printf/scanf family and the standard streams.
  • Dealing with files — fopen, fread/fwrite, fgets, fclose.
  • Error handling & resource management — check return values, feof/ferror, always close.

  Core concept — the FILE* stream: fopen returns a handle to a buffered stream; reads/writes go through that buffer and are flushed to disk on fflush/fclose, so failing to close can lose data.

  Key idea  A file handle is a resource just like heap memory: acquire it, check it opened, use it, and release it on every path — including error paths.

  K&R ch. 7 — input & output
• 9
  First Midterm

  First intermediate test covering modules 0–2 and file I/O: C fundamentals, error handling & testing, pointers, dynamic memory, structures/unions and file streams.

  Assessment  Counts toward the 20% intermediate-tests component (shared with the session-20 mid exam). Expect both conceptual questions and short coding tasks.

  assessment · part of 20%
• 10
  Preprocessor Directives and Macros · subtopic 3/3

  Commands that instruct the compiler before compilation, and macros for reusable inline code snippets and constants.

  • Preprocessor directives — #include, #define, #ifdef/#ifndef conditional compilation.
  • Function-like macros & constants — #define MAX(a,b) ((a)>(b)?(a):(b)); parenthesise arguments.
  • Include guards — prevent a header being processed twice.

  Core concept — textual substitution: the preprocessor runs before compilation and simply rewrites text — macros have no type checking and no scope, which is why over-using them is risky compared with const or inline functions.

  Key idea  Macros are powerful but blunt: wrap every parameter and the whole body in parentheses to avoid precedence surprises, and prefer real functions when types matter.

  K&R §4.11 — the C preprocessor

A tour of the techniques that distinguish fluent C: operating at the bit level, naming things well with enums and typedefs, building your first pointer-based data structure, and thinking recursively. Together these prepare you for the systems modules that follow.

By the end of this module you can

• Manipulate individual bits with & | ^ ~ << >> and pack flags into integers.
• Improve clarity with enum constants and typedef aliases.
• Implement a singly linked list with malloc'd nodes and pointer surgery.
• Design recursive solutions with correct base cases and apply backtracking.

• 11
  Bit Manipulation · subtopic 1/4

  Binary operations and manipulating individual bits for efficient, optimized solutions.

  • Bitwise operators — & mask, | set, ^ toggle, ~ invert, <</>> shift.
  • Famous tricks — Carmack's fast inverse square root, Morton codes for spatial hashing.
  • 1's vs 2's complement — how signed integers are represented in binary.
  • Using enums as flags — powers of two OR'd into one integer.

  Core concept — masking: to test a bit use x & (1u << n), to set it x |= (1u << n), to clear it x &= ~(1u << n) — the basis of compact flag sets and hardware registers.

  Key idea  Bit tricks turn many separate booleans into one fast integer and unlock optimisations the compiler can't infer — but they trade readability for speed, so comment them.

  demo: bit manipulation PCP — bit operations
• 12
  Enumerations and Typedef in C · subtopic 2/4

  Named-constant sets and custom type aliases to enhance readability, maintainability and efficiency.

  • enum for named constants — enum Color { RED, GREEN, BLUE }; auto-numbered from 0.
  • typedef for type aliases — typedef struct Node Node; drops the struct keyword.
  • Code readability & maintainability — self-documenting names instead of magic numbers.

  Core concept — naming as design: an enum gives a fixed set of states a name and lets the compiler/switch help you cover them; a typedef hides repetitive type spelling and makes intent clear.

  Key idea  Replacing magic numbers with enums and long type names with typedefs makes code read like its problem domain — fewer bugs, easier review.

  K&R §2.3 enums, §6.7 typedef
• 13
  Linked Lists · subtopic 3/4

  A fundamental dynamic data structure enabling efficient insertion, deletion and traversal.

  • Node = value + next pointer — struct Node { int v; struct Node *next; };
  • Insertion, deletion, traversal — relink next pointers; walk until NULL.
  • Dynamic storage vs arrays — O(1) insert/delete vs O(1) random access trade-off.

  Core concept — self-referential struct: a node contains a pointer to its own type, so a list is a chain of heap nodes ending in NULL; this brings together structs, pointers and malloc/free from Module 2.

  Key idea  Linked lists trade contiguous memory and random access for cheap insertion/deletion anywhere — the classic data-structure trade-off you'll weigh for the rest of your degree.

  demo: linked lists K&R §6.5 — self-referential structures
• 14
  Recursion and Backtracking · subtopic 4/4

  Solving problems by reducing them to smaller instances, and systematically exploring solution spaces by building and undoing partial solutions.

  • Recursion & base cases — a function that calls itself on a smaller input; the base case stops it.
  • The call stack — each call gets a frame; deep recursion risks stack overflow.
  • Backtracking — choose → recurse → undo, exploring a search tree (e.g. N-Queens).

  Core concept — recurrence + base case: a correct recursion needs a base case that returns without recursing and a recursive step that strictly shrinks the problem toward it, otherwise it never terminates.

  Key idea  Backtracking is recursion plus an "undo": tentatively make a choice, recurse, and if it leads nowhere, revert and try the next — the engine behind solving puzzles and constraint problems.

  demo: recursion & call stack demo: N-Queens backtracking

Modern machines have many cores; this module shows how to run parts of a program simultaneously and — harder — how to keep shared data correct when they do. It moves from creating threads to coordinating them safely.

By the end of this module you can

• Create, join and reason about the lifecycle of POSIX threads.
• Identify race conditions and protect critical sections with mutexes, semaphores and barriers.
• Recognise when higher-level frameworks (OpenMP, MPI) are the better tool.

• 15
  Thread Concepts & Lifecycle · subtopic 1/2

  Taking advantage of multi-core platforms where parts of a program execute simultaneously, using C's multithreading capabilities.

  • Why concurrency — multiple cores let independent work run in parallel.
  • Thread creation & lifecycle — pthread_create → run → pthread_join.
  • Basics of concurrent programming in C — passing arguments to and returning from threads.

  Core concept — thread vs process: threads of one process share the same address space (and therefore the same heap and globals), which makes communication cheap but means uncoordinated access to shared data is dangerous.

  Key idea  Concurrency can speed a program up, but shared mutable state is the source of nearly every concurrency bug — the next session is about taming exactly that.

  POSIX threads (pthreads)
• 16
  Advanced Thread Management · subtopic 2/2

  Handling common thread issues to build reliable, optimized programs.

  • Race conditions, shared/critical data, critical sections — when result depends on timing of interleaved access.
  • Synchronisation primitives — mutexes (lock/unlock), semaphores (counted access), barriers (rendezvous).
  • Higher-level constructs — OpenMP pragmas for shared-memory parallelism, MPI for message passing.

  Core concept — mutual exclusion: a mutex guarantees only one thread enters a critical section at a time, so a read-modify-write on shared data can't be interleaved; the cost is potential contention and, if misused, deadlock.

  Key idea  Protect the smallest possible critical section: too little locking causes races, too much serialises everything and throws away the speedup.

  pthreads · semaphores · OpenMP · MPI

The capstone technical module: writing C programs that talk over a network. It starts from the socket abstraction, builds client–server programs over TCP and UDP, secures them with TLS, and ends by surveying real networked applications. The second midterm sits inside it.

By the end of this module you can

• Explain what a socket is and use the Socket API to send and receive data.
• Build client–server programs and choose between reliable TCP and lightweight UDP.
• Reason about how TLS/HTTPS secures a connection with encryption and certificates.
• Recognise the architecture of real networked applications such as web servers.

• 17
  Socket Programming in C for Network Communication · subtopic 1/4

  Networking concepts and the Socket API to enable communication across networks.

  • Networking concepts — IP addresses, ports, the client/server roles.
  • What a socket is — an endpoint for communication, used through a file-descriptor-like handle.
  • Using the Socket API — socket, bind, connect, send/recv.

  Core concept — the socket as a file descriptor: once created, a socket is read and written much like a file, which is why network I/O reuses the same mental model as Module 3's file streams.

  Key idea  A socket is identified by an address+port pair; getting two programs to agree on that pair is the whole game of establishing a connection.

  HNP ch. 1–3 — networking & the socket API
• 18
  Client–Server Architectures using TCP and UDP · subtopic 2/4

  Network protocols and the client–server model across different transport protocols.

  • Introduction to network protocols — the layered model and where TCP/UDP sit.
  • TCP & socket I/O — listen/accept server loop; connection-oriented, reliable, ordered stream.
  • UDP & socket I/O — sendto/recvfrom; connectionless datagrams, no delivery guarantee.

  Core concept — TCP vs UDP: TCP gives a reliable, ordered byte stream at the cost of handshakes and buffering; UDP sends independent datagrams with minimal overhead but no guarantees — you pick based on whether the app needs reliability or low latency.

  Key idea  The server's accept loop and the client's connect are the canonical client–server pattern that underlies almost every networked program you'll write.

  HNP — TCP & UDP client/server
• 19
  Secure Connections with Sockets · subtopic 3/4

  Securing network connections using standard protocols via C.

  • HTTPS and TLS — TLS wraps a TCP socket to add confidentiality and integrity.
  • Encryption basics — symmetric vs asymmetric keys; the handshake that agrees a session key.
  • Certificates — how a CA-signed certificate authenticates the server's identity.

  Core concept — the TLS handshake: client and server use asymmetric crypto and a certificate to authenticate and agree on a shared symmetric key, then encrypt the rest of the conversation with that faster symmetric cipher.

  Key idea  Security isn't a feature bolted on at the end: TLS sits between your application and the raw socket, so "make it secure" means changing how you open and read/write the connection, not the business logic.

  HNP — TLS, HTTPS & secure sockets
• 20
  Mid Exam

  Second intermediate test, focusing on the advanced-C and networking material (bit manipulation, enums/typedef, linked lists, recursion, concurrency and sockets).

  Assessment  Together with the session-9 midterm this makes up the 20% intermediate-tests component.

  assessment · part of 20%
• 21
  Networked Applications · subtopic 4/4

  Reviewing real-world networked applications buildable with the course concepts.

  • Real-world networked applications — putting sockets, protocols and concurrency together.
  • Example: web servers — accept loop + request parsing + concurrent connection handling.

  Core concept — synthesis: a simple web server combines almost the whole course — sockets and TCP (Module 6), threads to serve clients concurrently (Module 5), buffers and parsing (Modules 2–3) and careful error handling (Module 1).

  Key idea  This is where the pieces click: the skills taught separately become one program that does something genuinely useful over a network.

  HNP — building networked applications

The final stretch turns knowledge into a deliverable: a collaboratively built C program, a look beyond C at programming paradigms, flexible lab time, revision, and the project presentations and final exam.

By the end you will have

• Designed, built, tested and documented a C program as a team.
• Presented and defended your project on functionality, code quality and best practices.
• Situated C within the wider landscape of programming paradigms (mainly OOP).

• 22
  Group Work Session

  Collaborative Program Development — develop a C program as a team, applying course concepts to a real-world problem.

  • Group formation — 3–5 members, self-selected or assigned for a mix of skills.
  • Program selection — a problem of moderate complexity exercising several course concepts.
  • Planning & design — objectives, required input/output, and the tasks to split.
  • Task allocation — modules, functions, debugging, testing, docs, integration.

  Key idea  Group work simulates real software development: communication and clean interfaces between members' code matter as much as the algorithms themselves.

  project · 20%
• 23
  Group Work Session

  Continued collaborative development: integration, testing/debugging and documentation of the group program.

  • Code integration — merge individual contributions into one cohesive program.
  • Testing & debugging — systematic error identification to ensure correctness.
  • Documentation — functionality, I/O spec, design choices, algorithms and per-member contributions.

  Key idea  The unit-testing and error-handling skills from Module 1 pay off here — a documented, tested integration is what gets evaluated, not just code that compiles.

  project · 20%
• 24
  Programming Paradigms (mainly OOP)

  Introduction to programming paradigms with a focus on object-oriented programming, set against the procedural style of C.

  • Procedural vs object-oriented thinking
  • Encapsulation, inheritance, polymorphism — the OOP pillars
  • How OOP ideas can be emulated in C (structs + function pointers)

  Key idea  C is procedural, but understanding OOP clarifies why certain C idioms (opaque structs, function-pointer tables) exist and prepares you for later object-oriented languages.

  paradigms · OOP
• 25
  Programming Paradigms (mainly OOP)

  Continued exploration of programming paradigms and OOP concepts, with examples contrasting them against the C techniques learned earlier.

  • Abstraction & modularity across paradigms
  • When each paradigm fits a problem
  paradigms · OOP
• 26
  Advanced Concepts (LAB)

  Flexible hands-on lab on advanced concepts, with the exact topics chosen depending on the progress of the course — extra time for the trickier material from earlier modules or a deeper dive on a topic of interest.

  lab · hands-on
• 27
  Revision

  Course-wide revision session ahead of final assessments — consolidating the six modules and clarifying open questions before the final project presentation and exam. :)

  revision
• 28
  Final Project Presentation & Evaluation

  Students present their final projects to the instructor and peers; evaluated on functionality, code quality, design principles and adherence to the best practices learned throughout the course.

  Assessment  The presentation is part of the 20% group project grade; be ready to explain design choices and individual contributions.

  project · 20%
• 29
  Final Project Presentation & Evaluation

  Continued final project presentations and evaluation, with feedback from the instructor and peers on each group's program.

  project · 20%
• 30
  Final Exam

  Final written exam covering the whole syllabus, consisting of multiple-choice and coding sections.

  Assessment  The single largest component at 50%; the June/July re-sit (if needed) is one comprehensive exam graded out of a maximum of 8.0.

  assessment · 50%