66 Declarations and call expressions — inside the act of calling

66.1 Three things kept apart — declaration, definition, call#

The same name appears in three places. The three do entirely different work.

A declaration is a promise, a definition is a thing, and a call expression is an event. This chapter is mostly about the third, but for the event to go right the first two must not contradict each other — and there are places where they can contradict each other with the compiler saying nothing at all. Those places produce the worst accidents in this neighbourhood (chapter 61).

66.1.1 A call expression is an operator#

Reading add(2, 3) as “the syntax for calling a function” misses something. In C’s grammar this is the postfix operator (), and its operands fall into two groups.

Two consequences follow at once. Since an expression may stand in the designator slot, that expression may have side effects of its own — tbl[i++](x). And since a function name decays to a pointer the moment it is used (chapter 68), add(2,3), (*add)(2,3) and (&add)(2,3) all mean the same thing.

★ The commas separating arguments are not the comma operator. f(a, b) passes two arguments; f((a, b)) passes one — inside the inner parentheses the comma becomes an operator, evaluates a, throws it away and yields b. The preprocessor counts macro arguments by the same distinction (chapter 65).

66.1.2 Functions without prototypes, tidied away by C23#

Functions without prototypes were a leftover from old C. C23 swept the leftovers out.

The gcc on this machine shows the difference directly. Given static int f() { return 1; }, a call f(2) draws nothing under -std=c17 and is cut down under -std=c23 with too many arguments to function 'f'. Empty parentheses moved from “unknown” to “none”.

★ The standard and the compiler can also disagree. First, where the compiler is ahead of the standard. The table’s second row — a call with no declaration — is what C23 made an error, and gcc 14 on this machine already errors on it under -std=c17. The compiler shut the door before the standard did.

★ “Removed” and “rejected by the compiler” are not the same. The old definition form is gone from the standard, yet this machine’s gcc still accepts it under -std=c23 with a single warning (-Wold-style-definition) — a courtesy to old code. clang, in the same place, makes it an error. What the standard removed and what your compiler tolerates must be checked separately.

66.2 Arguments arrive as if by assignment#

With a prototype in scope the compiler converts each argument to the parameter’s type as if by assignment (chapter 30). The returned expression is likewise converted to the return type. It all happens silently, which is a good reason to watch it once.

// With a prototype in scope, arguments are converted "as if by assignment".
#include <stdio.h>

static void takes_int(int n)
{
    printf("  the parameter holds %d\n", n);
}

static void takes_unsigned(unsigned n)
{
    printf("  the parameter holds %u\n", n);
}

// The same holds for the result --- the returned expression is converted
// to the return type.
static int truncating_return(void)
{
    return (int)3.99;              // spelling it out tells the reader
}

static char narrowing_return(void)
{
    int wide = 321;
    return (char)wide;             // 321 does not fit in a char
}

int main(void)
{
    puts("a double handed to an int parameter:");
    takes_int(3.7);                // arrives cut down to 3

    puts("a negative int handed to an unsigned parameter:");
    takes_unsigned(-1);            // wraps around

    printf("returning 3.99 as int: %d\n", truncating_return());
    printf("returning 321 as char: %d\n", narrowing_return());

    // Without a prototype this adjustment does not happen. Since C23 a call
    // with no prototype is an error, so the only unadjusted place left is ... .
    return 0;
}

a double handed to an int parameter:
  the parameter holds 3
a negative int handed to an unsigned parameter:
  the parameter holds 4294967295
returning 3.99 as int: 3
returning 321 as char: 65

3.7 arrives as 3, -1 wraps around in an unsigned slot, and 321 narrows into a char as 65. None of this is an error — like assignment, it simply converts.

The decay of arrays is where people are burnt most often. Writing int a[10] as a parameter still leaves the function receiving a single pointer.

// What is written as a parameter and what is received can differ.
#include <stdio.h>

// It says [10], but what arrives is a single pointer.
// (Writing sizeof a here earns -Wsizeof-array-argument from gcc.)
static void looks_like_array(int a[10])
{
    int *p = a;                    // the same thing --- the assignment draws no warning
    printf("  inside: sizeof(the parameter) = %zu\n", sizeof p);
}

// Written this way, "there are at least ten" becomes a contract (since C99).
static int sum_ten(int a[static 10])
{
    int total = 0;
    for (int i = 0; i < 10; i++)
        total += a[i];
    return total;
}

// Taking the length separately is the sound way.
static int sum_n(const int *a, size_t n)
{
    int total = 0;
    for (size_t i = 0; i < n; i++)
        total += a[i];
    return total;
}

int main(void)
{
    int v[10] = { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 };

    printf("outside: sizeof(v) = %zu\n", sizeof v);
    looks_like_array(v);
    printf("  the array itself never crossed the call --- only its address did\n");

    printf("sum via [static 10]: %d\n", sum_ten(v));
    printf("sum via pointer+length: %d\n", sum_n(v, sizeof v / sizeof v[0]));
    return 0;
}

outside: sizeof(v) = 40
  inside: sizeof(the parameter) = 8
  the array itself never crossed the call --- only its address did
sum via [static 10]: 55
sum via pointer+length: 55

Forty bytes outside, eight bytes inside — the array never crossed the call. Only its address did. Recovering the length inside with sizeof is therefore hopeless, and gcc says so outright: 'sizeof' on array function parameter 'a' will return size of 'int *'.

★ int a[static 10] is different. What arrives is still a pointer, but “there are at least ten” is now written down as a contract (chapter 55). The compiler may optimise on that promise, and breaking it is undefined behaviour — it is a place to write a promise, not a place to add a check.

66.3 The order of argument evaluation — what the standard declines to fix#

Here is the chapter’s first knot: the order in which arguments are evaluated. Within one call expression the arguments may be evaluated in any order. In the flesh:

// The order in which arguments are evaluated is not fixed by the standard.
// The same source may run in a different order under a different compiler.
#include <stdio.h>

static int step = 0;

// Prints its own name and reports which step it was.
static int mark(const char *who)
{
    step += 1;
    printf("  evaluated %s (step %d)\n", who, step);
    return step;
}

static void take(int a, int b, int c)
{
    printf("  the callee got a=%d b=%d c=%d\n", a, b, c);
}

int main(void)
{
    puts("call with three arguments:");
    take(mark("the first argument"),
         mark("the second argument"),
         mark("the third argument"));

    // The order *inside* one argument is another story again.
    step = 0;
    puts("one argument built from two calls:");
    take(mark("left of +") + mark("right of +"), 0, 0);
    return 0;
}

call with three arguments:
  evaluated the third argument (step 1)
  evaluated the second argument (step 2)
  evaluated the first argument (step 3)
  the callee got a=3 b=2 c=1
one argument built from two calls:
  evaluated left of + (step 1)
  evaluated right of + (step 2)
  the callee got a=3 b=0 c=0

The gcc on this machine evaluated the last argument first and worked backwards. The same source under clang evaluates the first argument first and works forwards. Changing the optimisation level between -O0, -O2 and -Os left each compiler’s habit intact.

Two things must be read apart here: the orders differing and modifying a value twice.

The orders differing is not itself an accident. The order of argument evaluation is unspecified; either choice runs the program as defined — only code written in reliance on an order falls apart. Indeed, in the second half of the demo the outer arguments went backwards while the two calls inside one argument went in source order. Even the summary “this compiler goes right to left” is not accurate.

Modifying a value twice is an accident. show(i++, i++) modifies one object twice with no order between the modifications, which is undefined behaviour. The a=1 b=0 and a=0 b=1 above are not “two of the possible answers” but two samples from a place where any answer is permitted.

printf("%d %d\n", i, i++);     /* undefined behaviour */
put(buf[k], buf[k++]);          /* undefined behaviour */

int before = i;
i += 1;
printf("%d %d\n", before, i);

66.3.1 Where there is an order#

Not everything is free. Between calls the discipline is quite definite.

That last row matters. In f(g(), h()) it is unknown whether g or h runs first, but g will not run halfway, hand over to h, and resume. The order is unspecified; the interleaving is forbidden. The standard cares enough to name the relation — indeterminately sequenced — and without it, calling any non-reentrant function from an argument slot would be unsafe.

66.4 One call, five steps#

Now the inside of the event. What does the single line add(2, 3) set in motion at machine level?

The return address of ② is the heart of the whole function mechanism. Because it is left on the stack, calls can nest, recursion works — and writing past that slot sends the program back to somebody else’s address (chapter 44).

Step ③ turns on one more agreement: who preserves what.

This split is what makes calls cheap. Saving every register on every call would turn one call into dozens of memory accesses; splitting the duty means most calls save nothing at all.

66.5 Register or stack — there is a budget#

Sending arguments in registers is fast, and registers are finite. So every calling convention sets a budget: this many go in registers, the rest go on the stack.

C has no syntax for asking whether an argument arrived in a register. It can still be seen indirectly. With optimisation off, register-borne arguments are spilled side by side into the callee’s own frame, while stack-borne ones stay where the caller put them. The two groups sit far apart, so measuring the distance between neighbouring arguments reveals the seam.

// Where do the arguments live --- the ones that came in registers, and the
// ones that came on the stack?
//
// C has no syntax for asking "did this argument arrive in a register?".
// But with optimisation off, the compiler spills register-borne arguments
// side by side into its own frame, while stack-borne ones stay where the
// caller put them. The two groups sit far apart, so *measuring the distance
// between neighbouring arguments* reveals the seam.
#include <stdio.h>
#include <stdint.h>
#include <stddef.h>

static void eight(int a, int b, int c, int d, int e, int f, int g, int h)
{
    const int *arg[8] = { &a, &b, &c, &d, &e, &f, &g, &h };
    ptrdiff_t widest = 0;
    int at = 0;

    for (int i = 0; i + 1 < 8; i++) {
        uintptr_t p = (uintptr_t)arg[i], q = (uintptr_t)arg[i + 1];
        ptrdiff_t gap = p > q ? (ptrdiff_t)(p - q) : (ptrdiff_t)(q - p);
        printf("  argument %d to %d: %td bytes apart\n", i + 1, i + 2, gap);
        if (gap > widest) { widest = gap; at = i + 1; }
    }
    printf("the widest jump is between argument %d and %d\n", at, at + 1);
}

int main(void)
{
    puts("a call with eight arguments:");
    eight(1, 2, 3, 4, 5, 6, 7, 8);
    puts("that jump is the seam between the register group and the stack group.");
    return 0;
}

a call with eight arguments:
  argument 1 to 2: 4 bytes apart
  argument 2 to 3: 4 bytes apart
  argument 3 to 4: 4 bytes apart
  argument 4 to 5: 4 bytes apart
  argument 5 to 6: 4 bytes apart
  argument 6 to 7: 152 bytes apart
  argument 7 to 8: 8 bytes apart
the widest jump is between argument 6 and 7
that jump is the seam between the register group and the stack group.

The addresses jump between the sixth and the seventh. That is where this ABI’s budget for integer arguments — six — runs out. Building the same program with clang gave a different jump width but the same jump position: it is not the compiler’s taste but the convention’s boundary.

Windows’ “shadow space” is an agreement that the caller leaves 32 bytes free for the callee to spill its register arguments into. The 32 bytes are left even when there are no arguments at all. Same CPU, same instructions, different promise (chapter 61).

66.5.1 When the side that clears the stack differs, so does the symbol name#

Several conventions coexisted on 32-bit Windows. They all pushed arguments on the stack; they differed in who cleaned up, so joining them wrongly left the stack quietly askew. The remedy of that era was to leave a trace in the name.

The single instruction ret $8 means “return, and take 8 bytes of stack with you”. And because of the @8 on the name, calling through a declaration with the wrong number of arguments makes the linker fail to find the name — a link error instead of silent corruption. It is a rare case of name decoration acting as a safety device.

66.6 Strange cases — ARM and the embedded world#

Seen from the desktop, conventions look like variations on “how big is the budget”. Down among small machines the rules get much stranger. Everything below comes from building one and the same declaration for different targets.

long long mix(int a, long long b, int c);   /* calling mix(1, 2, 3) */

66.7 Passing and returning structures#

What happens when one value does not fit in a register? Structures sit right on that boundary.

Code that passes large structures by value gives no hint of it in the source, yet a copy and a hidden argument come along. Where performance matters, the idiom that took hold is to pass a pointer and mark it const (chapter 48).

★ Rules of thumb like “16 bytes or less goes in registers” differ per convention and have many exceptions — when integers and floating-point members are mixed, System V classifies the structure in eight-byte pieces and sends some pieces in integer registers and others in floating-point ones. There is no need to memorise this. There is one thing to remember: the size and composition of a value change how it travels.

66.8 Functions that return function pointers#

If an expression may stand in the designator slot, then a function may produce that expression. It is also a good place to practise reading declarators.

// A function that returns a function pointer --- one thing, three spellings.
#include <stdio.h>

static int add(int a, int b) { return a + b; }
static int mul(int a, int b) { return a * b; }

// (1) The raw declarator. Read it from the inside out:
//     pick is a function taking (char), and its result is a pointer to
//     a function taking (int, int) and giving an int.
static int (*pick(char op))(int, int)
{
    return op == '+' ? add : mul;
}

// (2) Name the function type and the same thing reads as one line.
typedef int binop(int, int);      // a function type
static binop *pick_typedef(char op)
{
    return op == '+' ? add : mul;
}

// (3) Name only the pointer type --- the common compromise.
typedef int (*binop_ptr)(int, int);
static binop_ptr pick_ptr(char op)
{
    return op == '+' ? add : mul;
}

int main(void)
{
    printf("raw declarator: %d\n", pick('+')(3, 4));
    printf("function typedef: %d\n", pick_typedef('*')(3, 4));
    printf("pointer typedef: %d\n", pick_ptr('+')(10, 32));

    // What comes back is a value: keep it and call it later.
    binop_ptr f = pick('*');
    printf("stored and called later: %d\n", f(6, 7));

    // (*f)(...) and f(...) mean the same --- the name decays to a pointer anyway.
    printf("both spellings agree: %d %d\n", (*f)(2, 3), f(2, 3));
    return 0;
}

raw declarator: 7
function typedef: 12
pointer typedef: 42
stored and called later: 42
both spellings agree: 6 6

Read from the inside out. In int (*pick(char op))(int, int), pick is a function taking one char; its result is a pointer; and what that pointer points to is a function taking two ints and giving an int.

66.9 The accidents that happen around a call#

The places where this chapter’s rules are broken, gathered in one table. Most are caught by the compiler; the few that are not are the dangerous ones.

The third row is the most dangerous in the table, precisely because nobody catches it, and it can happen to look correct, so the accident surfaces late.

// Two files know the same function differently.
//
// Warning: this program is undefined behaviour. Neither the compiler nor the
// linker says a word --- each of them sees only its own file. The output
// below is not "the right answer": it is what this machine's calling
// convention happened to make of it.
#include <stdio.h>

// The definition takes two ints; this file declares two longs.
void report(long id, long value);

int main(void)
{
    puts("calling a function this file has mis-declared:");
    report(1, 2);
    puts("it linked, it ran, and it even looks right --- that is the danger.");
    return 0;
}

calling a function this file has mis-declared:
  report() as defined here: int id=1, int value=2
it linked, it ran, and it even looks right --- that is the danger.

The two files have never seen each other. Each compiler sees only its own file, and the linker sees only names — there is a report, somebody calls it, done. So the program builds without a single warning and on this book’s x86-64 machine even prints the right answer: a value sent as a long was received as an int, which under the System V x86-64 convention means reading the lower half of the same register, and it happened to fit.

The same reasoning explains where the luck runs out. Had the definition been void report(double) and the declaration void report(long), the caller would load an integer register while the callee reads a floating-point register — one nobody has written. The result is not slightly wrong but entirely unrelated.

/* a.c */                    /* b.c */
void report(long, long);     void report(int id, int value) { … }

66.10 Recap#

This chapter assumed calls where a prototype exists and the count and types match. The next chapter is where that assumption collapses — functions whose receiving side knows neither how many arguments arrived nor of what type. What must be promised instead, once this chapter’s adjustments are gone, is that chapter’s story.