C Programming

Question 1 (14)

(a) sizeof(struct Packet) = 24, alignment = 8. (6)

• flags:3 + kind:5 = 8 bits = 1 byte packed into one uint8_t storage unit → offset 0, size 1. (2)
• uint16_t id needs 2-byte alignment → 1 byte padding at offset 1, id at offset 2–3. (1)
• char tag[3] at offset 4–6 (char needs no alignment). (1)
• double value needs 8-byte alignment → next multiple of 8 after offset 7 is offset 8; 1 byte padding at offset 7, value at offset 8–15. (1)
• Total used = 16; struct alignment is 8 (largest member double), 16 is a multiple of 8 → no tail padding. Size = 16.

(Award full 6 for total 16 with correct offsets/padding. Note: corrected total is 16, not 24 — accept 16.) Alignment = 8. (1)

(b) 0x41200000, little-endian storage bytes low→high: (4)

• b0 = 0x00, b1 = 0x00, b2 = 0x20, b3 = 0x41. (2)
• Interpreting 0x41200000 as IEEE-754 float: sign 0, exponent 0x82=130 → 130−127=3, mantissa bits give 1.25 → 1.25 × 2^3 = 10.0. So u.f = 10.0f. (2)

(c) (4)

• Reading a union member other than the one last written is explicitly permitted in C99+ as type-punning; the standard allows accessing the "common initial sequence"/re-interpretation of the union's stored bytes. (2)
• Casting a uint32_t* to float* and dereferencing violates the strict aliasing rule (an object may only be accessed via a compatible type, its signed/unsigned variant, or char); float and uint32_t are not compatible, so this is undefined behaviour. (2)

Question 2 (12)

(a) Row-major contiguous storage 0..11. (6)

• *(p+5) = element index 5 = 5. (2)
• *(*(a+2)+1) = a[2][1] = 9. (2)
• *(a[1]+3) = a[1][3] = 7. (2)

(b) (3)

• a : type int[3][4], sizeof(a)=48.
• a[0] : type int[4], sizeof(a[0])=16.
• &a[0] : type int(*)[4], sizeof(&a[0])=8. (1 each)

(c) q has type int(*)[4], element size = 16 bytes; q += 2 advances 32 bytes; *q now refers to a[2] (the third row {8,9,10,11}). (3)

Question 3 (16)

(a) Four defects: (8, 2 each)

1. L1 buffer overflow (undersized alloc): malloc(strlen(prefix)+strlen(body)) omits the +1 for the null terminator; strcpy/strcat write one byte past the buffer.
2. L1 null dereference (unchecked malloc): if malloc returns NULL, L2 strcpy(out,...) dereferences NULL.
3. L4 use-after-free / returning freed pointer: free(out) then return out — caller uses a dangling pointer (use-after-free).
4. Logic/leak consequence: because out is freed and returned, either the freed memory is used (UAF) or if not freed the function would leak on early-return paths; the free-then-return is the core double problem. (Accept "returning pointer to freed memory" as defect 3 and the missing null-check as defect 2.)

(b) Corrected version: (5)

char *join(const char *prefix, const char *body) {
    size_t need = strlen(prefix) + strlen(body) + 1;
    char *out = malloc(need);
    if (!out) return NULL;                 /* handle failure */
    snprintf(out, need, "%s%s", prefix, body);
    return out;                            /* caller frees */
}

Marks: +1 size incl. terminator; +1 malloc null check; +1 snprintf with bound need; +1 no free before return; +1 returns pointer / correct. (Caller is responsible for free.)

(c) Valgrind memcheck on original with puts(join("Hi","!")) would report: (3)

• Invalid write of size 1 (heap buffer overflow past the malloc'd block by strcpy/strcat). (1)
• Invalid read / use of freed memory ("Invalid read", "Address ... is inside a block of size N free'd") when puts reads the freed buffer. (1)
• Also possibly "Invalid free" or definitely-lost / dangling. Any two distinct categories earn full marks. (1)

Question 4 (10)

(a) (5)

typedef int (*IntFn)(int);
 
void map_int(int *arr, size_t n, IntFn fn) {
    for (size_t i = 0; i < n; i++)
        arr[i] = fn(arr[i]);
}

Marks: +2 correct function-pointer parameter, +1 typedef, +2 loop body applying callback and storing back.

(b) (2)

map_int(v, 4, sq);

Afterwards v = {1, 4, 9, 16}. (+1 call, +1 contents)

(c) (3)

• The parameter int *arr (and equivalently int arr[4]) is a pointer — arrays decay to pointers when passed to functions — so the callee writes through the caller's actual memory: modifications persist. (2)
• But sizeof(arr) inside the function yields sizeof(int*) = 8 (pointer size), not 4*sizeof(int)=16, because the array bound in a parameter is ignored; relying on it to compute n would give the wrong count. Hence n must be passed explicitly. (1)

Question 5 (8)

(a) (6)

• (char)200 + (char)200: (char)200 (signed) = −56; both operands integer-promoted to int; result −56 + −56 = −112, type int. −112. (2)
• 1 << 31: shifting into (or past) the sign bit of a signed 32-bit int is undefined behaviour in C (result not representable in int). Undefined. (2)
• 5 & 3 == 3: == binds tighter than &, so this is 5 & (3==3) = 5 & 1 = 1, type int. The trap: programmers expect (5&3)==3 which would be 1==3=0. (2)

(b) (2)

• Signed integer overflow is UB, so the compiler may assume i never overflows; therefore i <= n is assumed eventually false and the loop terminates. If n == INT_MAX, i <= INT_MAX is always true, i++ would overflow — the compiler can legally optimise this into an infinite/unbounded loop or remove the bound check, silently changing behaviour. (2)

[
  {"claim":"struct Packet size is 16 with double at offset 8","code":"flags_kind=1; pad1=1; id=2; tag=3; pad2=1; value=8; total=flags_kind+pad1+id+tag+pad2+value; result=(total==16)"},
  {"claim":"0x41200000 as IEEE-754 float equals 10.0","code":"import struct; val=struct.unpack('<f', struct.pack('<I',0x41200000))[0]; result=(val==10.0)"},
  {"claim":"row-major evaluations 5,9,7","code":"a=[[0,1,2,3],[4,5,6,7],[8,9,10,11]]; flat=[x for row in a for x in row]; result=(flat[5]==5 and a[2][1]==9 and a[1][3]==7)"},
  {"claim":"5 & (3==3) equals 1 and (char)200+(char)200 signed = -112","code":"b=5 & (1 if 3==3 else 0); c=(200-256)+(200-256); result=(b==1 and c==-112)"},
  {"claim":"squaring {1,2,3,4} gives {1,4,9,16}","code":"v=[1,2,3,4]; r=[x*x for x in v]; result=(r==[1,4,9,16])"}
]