C for C++ Programmers: Origin Story

1. In C, what is the correct way to print text to the terminal?

• cout « “hello”;

  cout is C++. It needs iostream and operator overloading, neither of which exist in C.

• printf(“hello”);
• System.out.println(“hello”);

  That’s Java. C has no class system and no System namespace.

• print(“hello”);

  print (no f) is Python. C’s I/O function is printf — the f is for formatted.

2. Why do we compile with gcc instead of g++ in this tutorial?

• gcc produces faster binaries

  Both produce comparable binaries. Speed isn’t the difference; the language standard is.

• g++ cannot compile .c files

  g++ can compile .c files — that’s exactly the problem. It treats them as C++, silently allowing features that won’t exist in real C.

• gcc compiles as C — g++ would allow C++ features and hide the differences
• gcc is newer than g++

  Both are part of the GCC suite, same age. g++ is the C++ frontend; gcc is the C frontend. Choosing gcc enforces C-only semantics.

3. What does int main(void) mean in C, and how does it differ from int main()?

• They are identical in both C and C++

  In C++ they’re equivalent (both mean zero args), but in C they differ — main() is an old-style declaration meaning ‘unspecified arg list’.

• main(void) explicitly takes zero arguments; main() means unspecified arguments in C
• main(void) returns void; main() returns int

  Return type is the leading int, not the parameter list. The void inside the parens means ‘no arguments’, not ‘returns void’.

• main() is invalid C syntax

  int main() is legal C — just historically slack. The fix is to write void explicitly so the compiler can type-check argument-less calls.

4. A C++ program uses std::string name = "Alice"; std::cout << name.length();. Why can’t this approach work in C? (Select the most fundamental reason.)

• C doesn’t have a length() function

  C does offer strlen(). The deeper issue isn’t a missing function — it’s a missing object/method paradigm.

• C has no objects, methods, or operator overloading — strings are raw char arrays with no built-in operations
• C strings are immutable

  C strings are mutable — that’s part of the danger. The real obstacle is that name.length() requires methods, and C has none.

• C uses printf instead of cout, but otherwise strings work the same

  Just swapping printf for cout doesn’t help — name.length() and << still need objects and operator overloading. C lacks both.

5. Arrange the lines to write a minimal C program that prints "42" to the terminal. (arrange in order)

1. #include <stdio.h>
2. int main(void) {
3. printf("%d\n", 42);
4. return 0;
5. }

• #include <iostream>
• std::cout << 42 << std::endl;

1. What does printf("%.2f", 3.14159) print?

• 3.14159

  That’s the unformatted value. %.2f does truncate/round — to two digits after the decimal point.

• 3.14
• 3.1

  That would be %.1f. The number after the dot is the count of digits to keep.

• 3

  Truncating to integer is %.0f (or use %d if it’s already an int).

2. You want to print a literal % character. Which format string is correct?

• printf(“%”);

  A bare % is a partial format specifier — undefined behavior. printf expects a conversion character to follow.

• printf(“%%”);
• printf(“\%”);

  Backslash escapes are for C string literals (\n, \t). printf format specifiers escape % differently.

• printf(“%c”, ‘%’);

  Technically this works (%c prints the char '%'), but it’s an awkward workaround when %% is the idiomatic answer.

3. What happens if you use the wrong specifier, like printf("%d", 3.14)?

• It prints 3 (truncates to int)

  printf doesn’t convert — it reads raw bytes per the specifier. There’s no automatic float→int truncation step.

• The compiler prevents it — compile error

  With -Wall, gcc warns but it won’t refuse to compile. printf is a varargs function; the compiler can’t fully type-check it.

• Undefined behavior — the output is unpredictable garbage
• It prints 3.14 anyway because printf is smart

  printf has no runtime type info; it trusts the format string. The ‘smart’ option requires varargs introspection that doesn’t exist in standard C.

4. Arrange the printf arguments to correctly print: Player xX_SlayerKing_Xx has 42/100 XP (42.0%) (arrange in order)

1. printf("Player
2. %s has %d/%d XP (%.1f%%)
3. \n",
4. "xX_SlayerKing_Xx",
5. 42,
6. 100,
7. 42.0
8. );

• %f has %s
• "42",

5. [Interleaved: Revisit Step 1] Which of the following C++ features does NOT exist in C?

• Pointers

  Pointers are the soul of C — they predate C++ entirely.

• Structs

  Structs exist in C, just without methods or access modifiers.

• Function overloading
• Header files

  Header files (#include) are a C invention; C++ inherited them.

1. Why does scanf("%d", &age) need the & before age?

• & converts age from int to string

  & is the address-of operator, not a type conversion. C’s int↔string conversions go through sprintf/atoi/strtol.

• scanf needs the memory ADDRESS where it should store the result
• & is optional — it works either way

  Without &, you pass the value of age (garbage). scanf treats that garbage as an address and writes to a random location — undefined behavior.

• & tells scanf to read from a file instead of stdin

  scanf always reads from stdin. To read from a file, use fscanf (different function, different first argument).

2. What is the specific danger of scanf("%s", buffer) when the user types more characters than buffer can hold?

• scanf truncates the input automatically

  scanf with bare %s has no length limit at all — it would have to know the buffer size to truncate, and you never told it.

• The program prints an error and stops

  There’s no automatic check. The OS may not even notice until much later, when something else hits the corrupted memory.

• Buffer overflow — scanf writes past the end of the array, corrupting memory
• The extra characters are silently discarded

  Discarding characters would require length-aware reading. %s writes everything it reads, off the end of the array.

3. fgets(buf, 20, stdin) reads at most how many characters into buf?

• 20 characters

  Off-by-one. The size argument is the buffer size, not the chars-to-read count — fgets reserves one byte for \0.

• 19 characters (reserves 1 byte for the null terminator)
• 21 characters (20 plus the newline)

  Including the newline doesn’t increase the limit; the newline (if present) is part of the up-to-19 chars read.

• It reads until newline, regardless of the size argument

  fgets does respect the size cap — that’s the whole point compared to gets() (which the C standard removed entirely).

4. Arrange the lines to safely read a city name (max 30 chars), strip its trailing newline, and print it back as City: <name>. The pattern is the same as input_lab.c — but you must transfer it to a new buffer name, a new size, and a different output format. (arrange in order)

1. char city[30];
2. printf("Enter city: ");
3. fgets(city, sizeof(city), stdin);
4. strip_newline(city);
5. printf("City: %s\n", city);

• scanf("%s", city);
• gets(city);
• char city[1000];

5. [Interleaved: Revisit Step 2] What does printf("%05d", 42) print?

• 42 (3 spaces then 42)

  Space-padding is the default — %5d would give ` 42. The leading 0` flag flips to zero-padding.

• 00042
• 42000

  The padding is on the left (to reach the field width). To pad on the right, use the - flag (%-5d) — but that pads with spaces, not trailing zeros.

• 42.00

  That would require a float specifier (%.2f). %d is integer; there’s no decimal at all.

1. What does malloc(10 * sizeof(int)) return?

• An array of 10 integers initialized to zero

  That’s calloc(10, sizeof(int)). malloc doesn’t zero-initialize — the bytes are whatever was last in that memory.

• A pointer to 40 bytes of uninitialized memory (or NULL on failure)
• An integer with value 10

  malloc returns a pointer (a void*), not an integer. The argument to malloc is the byte count.

• A pointer to 10 bytes of memory

  The argument is the byte count. 10 * sizeof(int) is 40 bytes on most systems, not 10.

2. In C, should you cast the return value of malloc? E.g., int *p = (int*)malloc(...);

• Yes — C requires the cast just like C++

  C++ does require the cast (its void* rules are stricter), but C deliberately allows implicit void* conversion. The C answer differs from the C++ answer.

• No — in C, void* implicitly converts to any pointer type, and the cast can hide bugs
• Yes — otherwise you get a compile error

  It compiles fine without the cast — void* converts implicitly to any pointer type in C. (gcc may warn if you forgot <stdlib.h>, but the cast itself isn’t required.)

• It doesn’t matter either way

  It does matter — the cast can mask the bug of forgetting #include <stdlib.h>. Without the include, older C compilers default-typed malloc as returning int, and the cast silently converted the wrong-sized return value.

3. What happens if you forget to call free() on malloc’d memory?

• The program crashes immediately

  No immediate crash — that’s what makes leaks insidious. They compound silently over time.

• Nothing — the OS reclaims it when the process exits

  True for short-lived processes. But long-running programs (servers, daemons) keep accumulating leaked memory until they exhaust RAM and crash.

• Memory leak — the memory stays allocated, reducing available RAM; in long-running programs this is a serious bug
• The compiler warns you

  gcc/clang generally don’t warn on missing free. Tools like Valgrind or AddressSanitizer detect leaks at runtime, but the compiler lets them through.

4. Arrange the lines to dynamically allocate an array of 100 doubles, check for failure, use it, and clean up. (arrange in order)

1. double *data = malloc(100 * sizeof(double));
2. if (data == NULL) { return 1; }
3. data[0] = 3.14;
4. printf("%.2f\n", data[0]);
5. free(data);

• double *data = new double[100];
• delete[] data;

5. [Interleaved: Revisit Step 3] You write scanf("%d", age) (without &). What happens?

• scanf stores the value in age normally

  scanf gets the value of age (garbage), not a writable location. There’s no automatic ‘do the right thing’ fallback.

• Compile error — scanf requires a pointer

  scanf is varargs — %d doesn’t fully type-check at compile time. With -Wall, gcc warns, but it won’t refuse to compile.

• Undefined behavior — scanf interprets the uninitialized value of age as a memory address and writes to a random location
• scanf ignores the missing & and reads into a default location

  scanf has no default location to fall back to. Whatever bytes happened to be in age get reinterpreted as an address.

1. What is the length of the string "Hello" in memory (including the null terminator)?

• 5 bytes

  That’s strlen("Hello") — the count not including the terminator. The question asks about storage, which always reserves the extra byte.

• 6 bytes
• 7 bytes

  Off by one too many. Each visible char is one byte (5), plus exactly one \0.

• It depends on the system

  ASCII characters are always 1 byte, including the terminator — that’s a fixed C invariant. (Multi-byte chars exist in UTF-8 strings, but "Hello" is pure ASCII.)

2. Why can’t you use == to compare C strings?

• == is only for integers

  == works on any value type, including pointers — that’s the problem. It compiles fine; it just compares the wrong thing.

• == compares the pointer addresses, not the actual characters
• == triggers a compilation error on char arrays

  It compiles without error. The compiler sees pointer == pointer and accepts it. The bug is silent.

• == compares only the first character

  == doesn’t dereference at all. It compares the literal pointer values (memory addresses), not any characters.

3. Arrange the lines to safely copy a string from src into dest (size 20), ensuring null-termination. (arrange in order)

1. char dest[20];
2. char *src = "Hello, World!";
3. strncpy(dest, src, sizeof(dest) - 1);
4. dest[sizeof(dest) - 1] = '\0';
5. printf("%s\n", dest);

• strcpy(dest, src);
• dest = src;

4. [Interleaved: Revisit Step 4] After char *s = malloc(50);, what is the content of the 50 bytes?

• All zeros

  Zero-initialization is calloc’s job (calloc(50, 1)). malloc just hands you memory as-is.

• All null characters (\0)

  \0 is a zero byte — same case as ‘all zeros’. malloc doesn’t zero. Use calloc, or set s[0] = '\0' yourself.

• Uninitialized — garbage values from whatever was in that memory before
• Empty string

  An ‘empty string’ would mean s[0] == '\0', but malloc doesn’t initialize. The first byte could be anything.

1. Why do C programmers pass struct pointers to functions instead of passing structs by value?

• C doesn’t allow passing structs by value

  C does allow it (and structs are copied by value when you do). The reason to avoid it is cost + the inability to mutate the caller’s struct.

• Passing by value copies the entire struct — wasteful for large structs, and the function can’t modify the original
• Pointers are faster because they use less CPU

  Pointers happen to be smaller (8 bytes vs. however large the struct is), but speed isn’t the reason — it’s a side effect. The bigger reason is enabling mutation.

• Structs cannot be returned from functions

  C does allow returning structs by value (it works fine, just copies them). The pointer pattern is about parameter passing, not return values.

2. Given Character *c = &hero;, which syntax accesses the name field?

• c.name

  c.name would dereference c as if it were a struct — but c is a pointer, not a struct. c.name is a compile error.

• c->name
• *c.name

  Operator precedence trap: *c.name parses as *(c.name), which still treats c as a struct first. The correct form is (*c).name — or, more idiomatically, c->name.

• c[name]

  [] is for array subscripting and would treat c as a pointer to a (zero-indexed) sequence. Struct fields aren’t accessed positionally.

3. Arrange the lines to define a Rectangle struct and a function that calculates its area. (arrange in order)

1. typedef struct {
2. double width;
3. double height;
4. } Rectangle;
5. double rect_area(const Rectangle *r) {
6. return r->width * r->height;
7. }

• class Rectangle {
• return r.width * r.height;

4. [Interleaved: Revisit Step 5] Why does character_init use strncpy instead of strcpy for the name?

• strncpy is faster than strcpy

  Performance is roughly identical (sometimes strncpy is slightly slower because of the length check). Safety is the reason, not speed.

• strncpy limits the number of characters copied, preventing buffer overflow if the name is too long
• strcpy doesn’t work with struct members

  strcpy works fine with struct members syntactically — that’s part of the danger. It compiles and runs; it just overflows when the source is too long.

• strncpy automatically adds a null terminator

  Reverse of reality: strncpy may not null-terminate when src is at least as long as the limit. You have to add '\0' yourself.

5. In C++, you’d write p.translate(1, 1). The closest equivalent in idiomatic C is:

• p.translate(1, 1) — C supports method-call syntax on structs since C99

  C99 added many things, but methods are not among them. Member-access syntax (p.x) only reaches fields, never functions.

• translate(p, 1, 1) — pass the struct by value, modify the copy

  Passing by value would copy the struct and modify the copy — the caller’s p stays unchanged. To translate the original, you need a pointer.

• point_translate(&p, 1, 1) — module-prefixed function taking a Point * first argument
• p->translate(1, 1) — use the arrow operator to dispatch

  -> is for dereferencing struct pointers to access fields (pp->x). It’s not method dispatch — there are no methods to dispatch to in C.

1. A union with an int (4 bytes), double (8 bytes), and char[4] (4 bytes). What is sizeof this union?

• 4 bytes (smallest member)

  Smaller than the largest member would mean some members couldn’t fit — defeating the purpose. The union must hold any one member.

• 8 bytes (largest member)
• 16 bytes (sum of all members)

  That’s a struct, where every member has its own memory. A union shares one memory region across all members.

• Depends on the compiler

  Compiler-dependent in extreme cases (alignment padding), but the essential rule — sizeof(union) == sizeof(largest member) — is C standard.

2. What happens if you write to val.i and then read val.d (without writing to val.d first)?

• You get 0.0

  There’s no zero-initialization on type-punned reads. The bytes you wrote as an int are still there; reading them as a double gives a meaningless float.

• You get the integer value converted to double

  C does NO conversion when reading a different union member. It reinterprets raw bytes — the bit pattern of an int isn’t a valid double’s bit pattern.

• Undefined behavior — you’re reading bytes that were written as a different type
• The compiler prevents this

  The compiler can’t tell which member was ‘last written’ — that’s runtime state. Without runtime checks, there’s nothing to prevent you from reading the wrong member.

3. Arrange the lines to create a tagged union for a Shape that can be a circle (with radius) or rectangle (with width and height), and print the area. (arrange in order)

1. typedef enum { CIRCLE, RECT } ShapeType;
2. typedef struct {
3. ShapeType type;
4. union { double radius; struct { double w, h; }; };
5. } Shape;
6. if (s.type == CIRCLE) printf("%.2f\n", 3.14 * s.radius * s.radius);
7. else printf("%.2f\n", s.w * s.h);

• class Shape { virtual double area(); };

4. [Interleaved: Revisit Step 5] In the TaggedValue struct, the string member is char s[32]. If you assign strncpy(v.s, "hello", sizeof(v.s)), is the string safely null-terminated?

• Yes — strncpy always null-terminates

  Almost — but only when the source is shorter than the limit. With a longer source, strncpy stops without null-terminating, which is the gotcha to remember.

• Yes — because “hello” is shorter than 32 chars, strncpy will null-terminate in this case
• No — strncpy never null-terminates, regardless of input length

  Reverse: strncpy does null-terminate (and fills the rest with \0) when the source is shorter than the limit. The danger is the long-source case.

• It depends on the compiler

  strncpy’s behavior is fully specified by the C standard; it doesn’t vary by compiler. Compilers vary on warnings, not on this semantics.

5. A teammate writes print_value like this — no switch on the tag:

void print_value(const TaggedValue *val) {
    printf("int: %d, double: %.2f, string: %s\n",
           val->i, val->d, val->s);
}

• It prints all three fields side-by-side, which is more informative than the tag-based version

  Reading union members you didn’t write doesn’t give ‘all three values’ — it reinterprets the same bytes through three types. Two of the three readings are nonsense.

• It compiles fine, but reads union members other than the last-written one — undefined behavior, garbage output for two of the three fields
• It refuses to compile because a union allows only one access at a time

  The compiler can’t tell which member was last written — that’s runtime state. It accepts the code; the bug is at run time, not compile time.

• It works correctly only when the tag is set to TYPE_INT

  The bug isn’t tag-specific. Whatever the tag says, two of the three accesses still read bytes that were last written under a different type.

1. What does the declaration int (*fp)(double, double); mean?

• A function named fp that takes two doubles and returns an int pointer

  That’d be int *fp(double, double); — without the parentheses around *fp. Parens change everything; they bind * to fp first.

• A pointer to a function that takes two doubles and returns an int
• A double pointer to a function

  ‘Double pointer’ would be int (**fp)(...). One * is one level of indirection.

• A function that returns a pointer to an int

  That’s also int *fp(double, double); — function returning int. The parens around *fp are what make this a *pointer, not a function.

2. Why does qsort use void* parameters in its comparison function?

• void* is faster than typed pointers

  void* and typed pointers are the same size and have identical performance. The reason is genericity, not speed.

• C has no templates/generics, so void* is the only way to make qsort work with any data type
• void* automatically detects the element type

  There’s no auto-detection. The comparator function has to cast the void* back to the correct concrete type (you write the cast).

• void* prevents buffer overflows

  void* doesn’t add any safety. If anything, it’s less safe — the compiler can’t verify your casts inside the callback.

3. Arrange the lines to define a comparison function for sorting strings with qsort, then call qsort on a string array. (arrange in order)

1. int cmp_str(const void *a, const void *b) {
2. return strcmp(*(const char **)a, *(const char **)b);
3. }
4. char *words[] = {"banana", "apple", "cherry"};
5. qsort(words, 3, sizeof(char *), cmp_str);

• return *(char *)a - *(char *)b;
• std::sort(words, words + 3);

4. [Interleaved: Revisit Step 6] How do function pointers relate to structs in C?

• Structs automatically generate function pointers for each field

  There’s no auto-generation in C. You write everything by hand — including any function pointers you want to embed.

• You can store function pointers as struct members, simulating methods from C++
• Function pointers can only be used in global scope, not in structs

  Function pointers can live anywhere — local variables, struct fields, global, parameter. There’s no scope restriction on the type.

• Structs and function pointers are completely unrelated features

  They’re closely related when you want OO-like patterns. Embedding function pointers in structs is exactly how C simulates virtual methods (and how C++ implemented its first vtables).

1. What happens to an array when you pass it to a function in C?

• The entire array is copied onto the stack (pass-by-value)

  Arrays are NOT copied. (If they were, every C function call with a million-element array would be ruinously expensive.) C decays the array to a pointer instead.

• The array decays into a pointer to its first element — size information is lost
• The function receives a reference to the array (like C++)

  C has no references — that’s a C++ feature. The decayed pointer is the closest C gets, but there’s no & reference syntax.

• The compiler inlines the array into the function

  Inlining is a compiler optimization, unrelated to argument-passing semantics. Even with inlining, the language-level rule is decay-to-pointer.

2. A function void resize(int *p, int new_size) calls p = realloc(p, new_size * sizeof(int)) inside. After resize(data, 100) returns, what is data in the caller?

• Points to the resized memory

  That’s what you want, but C is strictly pass-by-value. The function reassigned its local copy of p, not the caller’s data.

• Unchanged — still points to the original (possibly freed!) memory
• NULL

  realloc returns NULL on failure but never auto-NULLs your variable. The caller’s data is whatever it was before the call — often pointing at freed memory now.

• Compiler error — can’t reassign a parameter

  Reassigning a parameter is legal in C — the parameter is a local variable. The compiler is happy; the caller is just unhelped by it.

3. Arrange the lines to write a function that doubles every element in an array, accepting the length as a parameter (since sizeof won’t work on a decayed array). (arrange in order)

1. void double_array(int *arr, int len) {
2. for (int i = 0; i < len; i++) {
3. arr[i] *= 2;
4. }
5. }

• int len = sizeof(arr) / sizeof(arr[0]);
• void double_array(int arr[100]) {

4. [Interleaved: Revisit Step 4] After free(p), what state is the pointer p in (using the pointer lifecycle model)?

• Null — free automatically sets pointers to NULL

  That’s what some other languages do, but C deliberately doesn’t. After free(p), the variable p still holds the same address — best practice is to set p = NULL; yourself right after.

• Dead — the pointer still holds the old address, but the memory is no longer valid
• Alive — free just marks the memory as available but the pointer is still usable

  The pointer value is still readable, but dereferencing it is undefined behavior. The memory it points to has been returned to the allocator.

• Uninitialized — free resets the pointer to its original state

  free doesn’t track or modify the pointer variable’s prior history. It just releases the memory the pointer was pointing at.

1. What happens if you open an existing file with fopen("data.txt", "w")?

• The file is opened for reading

  "w" is write mode, not read. Read mode is "r". Choosing the wrong mode is a top source of file-handling bugs.

• The existing contents are preserved, and new writes are appended

  Append mode is "a". "w" truncates first — that’s the data-loss footgun.

• The existing contents are DESTROYED — the file is truncated to zero length
• fopen returns NULL because the file already exists

  fopen happily opens existing files (the point is to write to them). Trying to truncate isn’t an error.

2. What does fgets(buf, 100, fp) return when it reaches the end of the file?

• An empty string

  An empty buffer would be ambiguous with a blank line in the file. fgets returns a sentinel NULL pointer instead.

• The number of bytes read

  fgets returns the buffer pointer (or NULL), not a count. For a count, use fread or look at strlen(buf) after a successful call.

• NULL
• EOF (a special integer constant)

  EOF is for character-level functions (fgetc, getchar). fgets returns a pointer; NULL is its end-of-file/error signal.

3. Why is it important to call fclose() on every file you open?

• It’s just good style — the OS closes files automatically when the program exits

  OS cleanup happens at process exit, but until then, your buffered writes sit in memory. Unflushed writes are silent data loss in long-running programs.

• Buffered writes may not be flushed to disk without fclose, causing data loss; also prevents file descriptor leaks
• fclose frees the memory used by the file contents

  fclose doesn’t free the file contents (those are on disk). It releases the OS-level file descriptor and flushes the I/O buffer.

• fclose is only needed for files opened in write mode

  Read-mode files also need fclose — leaked descriptors hit the per-process limit. Buffering matters mostly for writes; descriptor cleanup matters for both.

4. Arrange the lines to safely read all lines from a file and print them with line numbers. (arrange in order)

1. FILE *fp = fopen("input.txt", "r");
2. if (fp == NULL) { perror("open"); return 1; }
3. char buf[256];
4. int n = 1;
5. while (fgets(buf, sizeof(buf), fp) != NULL) {
6. printf("%d: %s", n++, buf);
7. }
8. fclose(fp);

• while (!feof(fp)) {
• fp.close();

5. [Interleaved: Revisit Step 3] How is fprintf(fp, "%s\n", word) related to printf("%s\n", word)?

• They are completely different functions with different syntax

  Format strings are identical between the two; only the destination differs. (printf is essentially fprintf(stdout, …).)

• fprintf writes to a file (FILE*); printf writes to stdout. Otherwise identical format strings.
• fprintf is safer because it does bounds checking

  Neither does bounds checking — both read raw bytes per the format string. For bounds-checked sprintf, use snprintf.

• printf is a macro that calls fprintf(stdout, …) internally

  Close, but printf isn’t a macro in standard C — it’s a regular varargs function. Conceptually it does what fprintf(stdout, ...) does.

1. Why must you save curr->next BEFORE calling free(curr) in list_free?

• free() modifies the next pointer to NULL

  free() doesn’t touch the contents of the freed memory. The bytes might still look the same right after, which is what makes use-after-free so insidious — the bug is silent until something else reuses the memory.

• After free(curr), the memory at curr is released — accessing curr->next is a use-after-free bug (undefined behavior)
• free() returns the next pointer automatically

  free() returns void — no value at all. The function takes a pointer and returns nothing.

• It’s a style convention — either order works

  Order matters — this isn’t style. Reading curr->next after free(curr) is undefined behavior, the same kind of bug that causes ‘works in debug, segfaults in production’ nightmares.

2. In typedef struct Node { ... struct Node *next; } Node;, why do we need both the struct tag Node and the typedef name Node?

• They serve the same purpose — either one would work

  Try removing one — the compiler complains. Inside the struct body the typedef doesn’t exist yet, so self-references need the struct tag.

• The struct must reference itself using the struct tag (struct Node *next) because the typedef isn’t complete until the closing }
• The typedef must match the struct tag name

  The names can match (they often do, by convention) but they don’t have to. typedef struct Node { ... } MyNode; is legal — what matters is using the tag inside the body.

• The struct tag is for the compiler, the typedef is for the linker

  C has no special compiler/linker split for tags vs typedefs. Both live in the same compilation unit; the tag is needed during the definition because the typedef name isn’t bound until after the closing }.

3. Arrange the lines to free a linked list without leaking memory or causing use-after-free. (arrange in order)

1. Node *curr = head;
2. while (curr != NULL) {
3. Node *next = curr->next;
4. free(curr);
5. curr = next;
6. }

• curr = curr->next;
• free(next);

4. Arrange the lines to create a node, insert it at the tail of a linked list, and update the tail pointer. (arrange in order)

1. Node *new_node = malloc(sizeof(Node));
2. new_node->value = val;
3. new_node->next = NULL;
4. tail->next = new_node;
5. tail = new_node;

• new_node->next = tail;
• head = new_node;

5. [Evaluate] Your main() keeps both a head and a tail pointer. A teammate proposes simplifying it to only a head pointer — every insertion would walk to the end of the list before linking the new node. For a list of N existing nodes, what’s the cost of inserting one new node at the tail under each design?

• head+tail: O(1). head-only: O(1). Pointers are free, so the design choice doesn’t matter.

  Pointer arithmetic is free; the cost is the traversal. Without a tail pointer, you’d visit each existing node before linking the new one.

• head+tail: O(1). head-only: O(N). Without a tail pointer, every insertion walks the entire list.
• head+tail: O(N). head-only: O(1). Maintaining the tail adds bookkeeping overhead per insert.

  Maintaining tail is two assignments per insert (tail->next = new; tail = new) — that’s O(1). The traversal in the head-only design is what dominates.

• Both are O(log N) because linked lists have logarithmic access.

  Linked lists don’t have logarithmic access at all — that’s balanced trees. Linked lists give you O(1) at the head and O(N) anywhere else.

6. [Final Integration] Which of the following C features have you used in the linked list program? (Select all that apply) (select all that apply)

• Structs with typedef for the Node type
• malloc/free for dynamic memory management
• Pointers for linked list traversal and modification
• printf/scanf for I/O