Question bank — Variadic functions — va_list, va_start, va_arg, va_end

False. Once you write ..., the compiler stops verifying types and counts; that trust is the whole cost of the feature and the source of most UB.

False. It is an opaque type — on some ABIs it is a struct (or an array!) tracking register-save areas, so ap + 1 or sizeof(ap) is meaningless and non-portable.

False. Because it may be an array type, dst = src can fail or alias the same cursor; the only portable duplication is ==va_copy(dst, src)==.

False. C requires at least one named parameter, because va_start needs its name as the anchor to find where ... begins.

False. Some ABIs allocate cleanup state in va_start; skipping va_end is UB even if it "works" on your machine today.

False. Nothing marks the end of the list, so an extra read pulls whatever bytes follow — garbage, another variable, or a crash. Pure UB.

False. A float is promoted to ==double== before being passed; the float never exists in the call. You must read va_arg(ap, double).

False. It usually compiles (maybe with a warning); at runtime %d reads an int-sized chunk of a double's bytes → garbage. The format string is trusted blindly.

False. A va_list may be single-use with no rewind. To scan twice you must va_copy a fresh cursor before consuming the first.

False. va_start(ap, last) positions the cursor just after last, so the first va_arg returns the first ... argument, never last itself.

Two errors: no named parameter is allowed with a bare ..., and va_start's second argument must be a name, not ....

The char was promoted to int; reading char mis-sizes the slot. Use va_arg(ap, int) then narrow: char c = (char)va_arg(ap, int);.

The third va_arg(ap, int) reads past the arguments → UB. The count must match the number actually supplied.

The caller forgot the terminating NULL, so the while loop never sees the sentinel and reads past the end → UB. Caller must pass NULL.

Missing va_end(ap) — cleanup is mandatory on every path, including early returns and error branches.

A copied va_list is its own cursor and needs its own va_end(ap2); leaking it is UB just like leaking the original.

An array decays to a pointer, so the argument is actually an int* — that read is fine; the error would be reading it as int. (Trap: the mismatch is the assumption, not the code.)

At the call site it sees the actual arguments, but inside the function body it only sees ... — there is no per-call type information stored anywhere for va_arg to consult.

Because the real layout depends on registers, alignment, and calling conventions that differ per ABI; macros keep your code portable while the compiler fills in the platform details.

Default Argument Promotions widen char/short→int and float→double so every argument lands in a uniform, register-friendly size — there is literally no way to transmit an un-promoted char.

Nothing in the calling convention records how many arguments arrived, so the callee has no intrinsic way to know when to stop; you must encode the boundary yourself.

It reads arguments strictly according to the format string; if an attacker controls that string (printf(user)), they can make it read arguments that were never passed, leaking or corrupting memory.

The cursor must begin exactly where the named parameters end; last is the landmark from which "the byte after this" locates the first variadic argument.

It only advances a cursor by the size you name; it has no record of what was actually pushed, so it will happily reinterpret whatever bytes are there.

That is legal — you simply never call va_arg. The count/sentinel logic must handle the "0 items" case (e.g. average returning 0.0 when n == 0).

Yes, but pass it (or a va_copy) carefully — after the callee consumes it, the cursor position in the caller may be indeterminate. This is why vprintf/vsnprintf exist, taking a va_list parameter.

It is defined only if the actual argument had exactly that type; there is no promotion for structs, so the type must match the pushed struct exactly or it's UB.

Undefined behavior — each va_start must be paired with its own va_end before re-initialising; overlapping starts corrupt the cleanup state.

Yes — long double is not promoted (it's already the widest float), so you read it exactly as va_arg(ap, long double). Beware: it differs in size from double, so mismatching them mis-sizes the cursor.

Just after b, the last named parameter — both a and b are skipped, and the first va_arg returns the first ... argument.

Not always — a bare 0 may be passed as int, but the reader expects a pointer width. On platforms where they differ, this mismatches; use (void*)NULL or (char*)NULL to force pointer size.