bhylu.com

Advertisements

C Study Plan

Use a sequence of observable milestones instead of measuring progress by the number of pages opened.

Your brief

Start by compiling a one-file program and explaining its output. Next, model small measurements with explicit units and boundary tests. Continue through array bounds and terminated text before pointers. Learn function contracts before sharing addresses, and ownership before dynamic collections. Only then add stream parsing, files and modular builds. Finish by selecting a project, writing its input and failure contracts, and checking it with deliberately awkward fixtures. This is a suggested route, not a saved progress profile or a fixed-duration promise.

Run it locally

Use a hosted C17 compiler in a separate lab folder. The command assumes a driver named cc; substitute gcc, clang or zig cc as appropriate. C does not currently run in Bhylu’s browser playground. Apache, PHP and MySQL are not needed for these C programs.

cc -std=c17 -Wall -Wextra -Wpedantic -Werror study-plan.c -o lesson

On Windows, use -o lesson.exe and run .\lesson.exe in PowerShell. On Unix-like systems run ./lesson. Math-library linking differs by toolchain; GCC on many Unix systems needs -lm after the source.

Download the complete C source. File-writing labs must run in an empty private directory, away from existing reports.

Worked solution

Show the worked solution
C17 · study-plan.c

#include <stdio.h>

int main(void) {
    const char *milestones[] = {"Build and explain", "Validate and bound", "Own and release", "Parse and test", "Review a project"};
    for (size_t i = 0; i < sizeof milestones / sizeof milestones[0]; ++i) {
        printf("%zu. %s\n", i + 1, milestones[i]);
    }
    return 0;
}

Expected result

1. Build and explain
2. Validate and bound
3. Own and release
4. Parse and test
5. Review a project

Each milestone asks for evidence: a clean build, a predicted result, a rejection test, a lifetime explanation or a reviewed project. The small listing uses earlier array-of-text knowledge to print the sequence. Spend more time on a weak milestone rather than racing into later syntax. Keep source and tests under version control so a future change can be reviewed against known behaviour.

Extend and test

Pick the first milestone you cannot yet demonstrate. Build one tiny example, predict its output and explain one failure boundary before continuing.

For language and library rules, consult the WG14 C working group and its public C11 committee draft, which describes the core facilities used here; C17 incorporates corrections. Check your compiler and runtime documentation for implementation details.

Advertisements