CC     = gcc
CFLAGS = -std=gnu23 -Og -g3 -Wall -Werror -Wextra -Wwrite-strings
OUT    = out
BIN    = $(OUT)/tinybox

all: $(BIN)

# Any out/<name> from <name>.c, e.g. `make out/scratch`
$(OUT)/%: %.c Makefile | $(OUT)
	$(CC) $(CFLAGS) -o $@ $<

$(OUT):
	mkdir -p $@

tinybox: $(BIN)
scratch: $(OUT)/scratch

run: $(BIN)
	./$(BIN)

clean:
	rm -rf $(OUT)

.PHONY: all run clean tinybox scratch

Rules

target: prerequisites
	recipe

• make rebuilds target if it doesn’t exist or any prerequisite is newer (by file modification time). That’s the whole algorithm.
• The recipe lines must start with a tab. Spaces give *** missing separator. Stop.
• A rule with no recipe (tinybox: $(BIN)) just says “to make this, make that”.

Variables

CC, CFLAGS are conventional names (make’s built-in rules use them too). Use with $(NAME). Override from the command line: make CFLAGS=-O2.

Automatic variables

Inside a recipe:

• $@: the target (out/tinybox)
• $<: the first prerequisite (tinybox.c)
• $^: all prerequisites

The default target, and why it’s called all

Plain make builds the first target in the file, whatever its name. Calling it all is a convention (GNU Coding Standards), not a requirement.

Pattern rules

$(OUT)/%: %.c means “out/<anything> is built from <anything>.c”. One rule covers out/tinybox, out/scratch, and any future file. Some IDEs (e.g. CLion) only list named targets, which is why tinybox: and scratch: exist as aliases.

The Makefile as a prerequisite

If only tinybox.c is listed, changing CFLAGS doesn’t trigger a rebuild: make says Nothing to be done and your new warning flag silently does nothing. Listing Makefile fixes that. ($< still picks tinybox.c, since it’s first.)

Order-only prerequisites: | $(OUT)

Everything after | must exist before the recipe runs, but its timestamp is ignored. That matters for directories: a directory’s mtime changes whenever a file inside it is added or removed, so as a normal prerequisite it would make targets look out of date constantly.

.PHONY

Marks targets that are names, not files. Without it:

• A file called clean in the directory would make make clean think it’s up to date.
• make goes looking for built-in rules. It has one for foo from foo.c, so without .PHONY, make tinybox would build out/tinybox and then run gcc $(CFLAGS) tinybox.c out/tinybox -o tinybox, building a stray ./tinybox and feeding the binary in as an extra input. Phony targets skip the built-in rule search.

(Fun fact: with no Makefile at all, make scratch works: the built-in rule runs cc scratch.c -o scratch.)

Handy flags

• make -n: dry run, print the commands without running them
• make -B: rebuild everything regardless of timestamps
• make -p: dump the database, including all built-in rules

References: info make (the GNU make manual), especially “Rule Syntax”, “Pattern Rules”, “Automatic Variables”, “Phony Targets”, “Prerequisite Types”.

scratch.c:3:13: error: initialization discards 'const' qualifier from pointer target type [-Werror=discarded-qualifiers]
    3 |   char *s = "scratching surface";
      |             ^~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors

Line 1: file:line:col: severity: message [flag]

• scratch.c:3:13: where. Columns start at 1. Most terminals/editors make this clickable.
• severity: error stops the build; warning doesn’t; note: adds context to the diagnostic above it.
• [-Werror=discarded-qualifiers]: the flag that controls this check. -Werror= means it’s really the warning -Wdiscarded-qualifiers, promoted to an error by -Werror. Search man gcc for /Wdiscarded-qualifiers. -Wno-<name> disables it, which is rarely the right fix.

The message has a fixed vocabulary

The first words say where in the code the problem is:

The rest says what’s wrong. Here: “discards ‘const’ qualifier” = a const would be lost (const/volatile are qualifiers); “from pointer target type” = the const is on the thing pointed to, not on the pointer.

Lines 2–3: the source excerpt

^ marks the column, ~~~ underlines the whole expression it’s blaming: here the literal, not s.

note: lines: compare the types

Type errors usually come with a note giving both types:

error: passing argument 2 of 'execv' from incompatible pointer type
note: expected 'char * const*' but argument is of type 'const char * const*'

Put them side by side and read each right to left. The difference is the bug.

The last line: who’s talking

gcc is a driver that runs a pipeline: preprocessor → cc1 (the compiler) → as (assembler) → ld (linker, errors show up via collect2). The prefix tells you which stage complained. undefined reference to 'foo' with no line number = linker: compilation succeeded, the final link couldn’t find foo.

Habits

• Fix the first error first. One missing ; or } can cause a cascade.
• Read the note:s.
• Look the flag up in man gcc before silencing it.

char * const argv[]
            argv[]   → argv is an array
      * const        → of const pointers
char                 → to char

Rules of thumb:

• [] and () next to the name bind first (“array of”, “function returning”).
• Then read leftward: each * is “pointer to”.
• A const applies to whatever is immediately to its left; if nothing is to its left, it applies to the thing on its right.

The duplicate-const trap

static const char const *v[];   // looks like "const pointers to const chars"

Both consts are left of the *, so both apply to char: you’ve made the chars const twice and the pointers not at all. GCC says:

error: duplicate 'const' declaration specifier [-Werror=duplicate-decl-specifier]

What was meant: const char *const v[]. The const for the pointer goes after the *.

Why execv takes char *const argv[]

int execv(const char *path, char *const argv[]);

exec promises not to repoint the slots, but not to leave the chars alone, even though it never writes to them. The fully-const signature would have been const char *const argv[], but C won’t implicitly convert char ** to const char *const *, so every existing caller would have needed a cast. POSIX kept the old signature and documents that the strings aren’t modified (man 3p exec, RATIONALE).

The other direction bites if you write const-correct code:

error: passing argument 2 of 'execv' from incompatible pointer type [-Wincompatible-pointer-types]
note: expected 'char * const*' but argument is of type 'const char * const*'

The usual answer is an explicit cast at the call, (char *const *)argv, which is safe because of the POSIX guarantee. (In GCC 14+ incompatible pointer types are an error by default, even without -Werror.)

References: man 3 exec, man 3p exec; cdecl.org to check your reading.

char *p = "/bin/sh";   // compiles without a warning by default
p[0] = 'X';            // undefined behavior; in practice SIGSEGV

$ ./ub
Segmentation fault        (exit status 139 = 128 + SIGSEGV)

-Wwrite-strings: make the compiler tell you

-Wwrite-strings gives literals the type const char[N], so pointing a plain char * at one becomes a warning (an error with -Werror):

scratch.c:3:13: error: initialization discards 'const' qualifier from pointer target type [-Werror=discarded-qualifiers]
    3 |   char *s = "scratching surface";
      |             ^~~~~~~~~~~~~~~~~~~~

The fix is to say what you mean: const char *s = "...";. It’s not part of -Wall or -Wextra; you have to add it yourself.

Pointer to a literal vs. array initialized from one

char *s = "/bin/sh";   // A
char  s[] = "/bin/sh"; // B

They look almost identical but are very different:

• A is a pointer. It points at the literal itself, in .rodata. With -Wwrite-strings this is the error above.
• B is an array of 8 chars (7 + '\0'). The literal is only its initializer: the bytes are copied into the array. No pointer, no const dropped, and the array is yours to modify.

More differences:

• A can be repointed (s = "other";). B can’t: arrays aren’t assignable, only their contents are.
• sizeof s is the pointer size for A and the array size for B. For "/bin/sh" both happen to be 8 on a 64-bit machine; use a longer string to see them differ.

The real question isn’t “binary or stack”, it’s “am I pointing at the literal, or do I own a copy?”

References: the C23 standard, sections “String literals” and “Initialization”; man gcc (-Wwrite-strings).

• .data and .rodata are both in the binary; “in the binary” doesn’t mean read-only. The section decides that.
• .bss takes no space in the file (type NOBITS): the loader just hands out zeroed memory.
• Writing to .rodata (e.g. through a pointer to a string literal) → the page isn’t writable → SIGSEGV.

See it yourself

Sections and their flags (A = alloc, W = write, X = exec):

readelf -SW ./prog | grep -E '\.text|\.rodata|\.data |\.bss'

  [12] .text    PROGBITS ... AX
  [14] .rodata  PROGBITS ... A
  [22] .data    PROGBITS ... WA
  [23] .bss     NOBITS   ... WA

Sections are grouped into segments (readelf -lW ./prog, the LOAD lines), and segments are what actually get mapped. At runtime, compare addresses (printf("%p", (void *)ptr)) against /proc/self/maps:

aaaabfd80000-aaaabfd81000 r-xp ... /path/to/prog   <- .text + .rodata (literal was here)
aaaabfd9f000-aaaabfda0000 r--p ... /path/to/prog   <- RELRO (.got etc., made read-only after startup)
aaaabfda0000-aaaabfda1000 rw-p ... /path/to/prog   <- .data / .bss (static array was here)
ffffe15ba000-ffffe15db000 rw-p ...  [stack]         <- local array was here

Note: on this arm64 build .rodata shares the r-xp segment with .text. Other toolchains (e.g. x86-64 with -z separate-code) give it its own r--p mapping. Either way: not writable.

References: man 5 elf, man 1 readelf, man 5 proc (/proc/pid/maps).