When is an object passed to a function?

Question

Trying to clearly state the semantics of a function call.

In calling a function, are the arguments passed to the function the ones the calling code initially gives or the ones the function receives?

---

With code like below, the calling code in bar() calls foo() twice. This first time with int 2, then ...

1) Function foo() is called with a double 3.1, x has the converted value of int 3,

or

2) The value double 3.1 is converted to int 3 and function foo() is called,

or

3) Something else.

IOWs, is the conversion of double 3.1 to int 3 part of the call of a function (the conversion would not happen without the function call) or is it a preceding activity (consider to be part of the calling code) before the function call?

void foo(int x);

void bar() {
  foo(2);
  foo(3.1);
}

This query is primarily C, yet language agnostic thoughts appreciated. A quick answer is not needed.

[Edit]

Note: This is not an question of how platforms create the binary/executable to implement the program code - just about the code/language.

[Edit 2] @ Erik Eidt useful comment provided better words to use (at least for C) for this question.

Perhaps a more succinct question would be, from the language perspective: "Are functions called with "actual arguments" or "formal parameters"?

C11 3.3 actual arguments and 3.16 1 formal parameter.

Answer 1

I expect in every implementation of C, the conversion happens first. The psuedo-assembly for bar:

store 2 in argument-register-0
call foo
store 3.1 in temporary-register-0
convert-to-int temporary-register-0 into temporary-register-1
store temporary-register-1 in argument-register-0
call foo

Your optimizer is probably smart enough to eliminate temporary-register0 and/or temporary-register-1, and different assembly versions may need to do extra trickery to deal with floating point - but the core steps are generally the same.

Answer 2

Conversion is always done by the calling code, not in the called function (in particular because types get erased at runtime: the implementation does not know about types at runtime, only at compile-time). A C function which is declared (at least those which are not variadic, e.g. without ... ending there argument type list, like printf) has a well defined signature, given by its prototype.

^{Practically, every called function should have a prototype these days, often provided in some header file.}

This is covered by §6.5.2.2 Function Calls of the standard (citing the n1570 draft of C11 standard, paragraph 7):

If the expression that denotes the called function has a type that does include a prototype, the arguments are implicitly converted, as if by assignment, to the types of the corresponding parameters, taking the type of each parameter to be the unqualified version of its declared type.

So your case 2 apply.

Practically speaking, on many implementations of the C standard, the ABI document specifies the calling conventions. Read as an example the SVR4 ABI for x86-64. Often, arguments (at least the first few ones) are passed in registers, and different registers are used for int formals and for double ones. Since you gave a prototype for foo its int argument is required to be passed by the %rdi register (and %xmm0 would be used to pass a float formal argument) so the calling code in the caller function would load that integer register (perhaps by converting a float value).

BTW, in your example foo(3.1) the conversion to 3 is likely to be optimized by the compiler at compile time (constant folding) so the compiler would very probably emit the same assembler code as for foo(3) since you declared with a prototype void foo(int x); before the call.

If using GCC you should compile some simple sample code in file foo.c with gcc -fverbose-asm -Wall -O -S foo.c and look into the generated assembler file foo.s

There are some languages (like Common Lisp, Scheme, Perl, Python, Ruby) with dynamic typing. Then, each value knows its type (it is often represented in machine as some aggregate or structure with some of the fields giving the type) and your question does not really make any sense (you could understand that these language implementations handle only one value type, which would be a tagged union).

Answer 3

In C++ you have function overloading, that is given a series of functions with the same name but different input parameters (the return value is not considered) the compiler must look for the better pick, taking into account implicit conversions and namespace resolution.

So functionally the compiler finds a function call with a given input, and then looks if some overload fits the bill.

There could be well be more than one possible eligible overload, so it tries to find the best one which is then called.

In this sense the conversion is done before calling, since at first you don't even know which function to call.

Answer 4

Consider a language L0 that does no implicit conversions like double to int, "default argument promotions", array conversions to "address of first object", etc. Code like foo(int); double x; foo(x); is then a compile time error.

double x;
foo(x); // Bad L0 code

L0 is not relevant to this question other than it shows if L0 code wanted to call foo(int) with a double, it would explicitly perform the conversion.

double x;
foo(double_to_int(x));  // L0: Explicit conversion before calling `foo()`.

---

Consider a language L1 that does all the above implicit conversions. When code has a call to function foo(int) and a double parameter is passed, a function is created that that accepts the double, converts it to an int and then performs the code of foo(int). The L1 compiler has at least 4 choices: make 2 independent functions, 2 functions where one calls the other, makes one function with multiple entry points: one for int arguments and another for double, or one function with type information added in the passed argument.

double x;
foo(x); // Good L1 code, no conversion done in the calling code.

---

C is certainly not LO with C's implicit conversions. C could be L1 as there is little in the C spec that defines how to organize its passing of arguments - its ABI. As @Erik Eidt provided with useful comments to some key definitions, a language like C (and L1), which has a potential difference between actual arguments and formal parameters.

This muddies the boundary between calling code and the called function.

---

In the end, with C, it is the formal parameter definition which says "acquires a value on entry to the function" implying the function is not called yet until this point.

---

Ref

C11 3.3
actual argument
expression in the comma-separated list bounded by the parentheses in a function call expression, or a sequence of preprocessing tokens in the comma-separated list bounded by the parentheses in a function-like macro invocation

C11 3.16
formal parameter
object declared as part of a function declaration or definition that acquires a value on entry to the function, or an identifier from the comma-separated list bounded by the parentheses immediately following the macro name in a function-like macro definition