Can I call a function taking a long parameter with an int argument?

Question

Is this code undefined behavior?

extern long f(long x);

long g(int x)
{
    return f(x);
}

According to the C11 standard, in 6.5.2.2 §6:

If the function is defined with a type that includes a prototype, and [...] the types of the arguments after promotion are not compatible with the types of the parameters, the behavior is undefined.

In the example above, the function f is defined with a type that includes a prototype and the type of the argument x is int while the type of the parameter x is long. According to 6.2.7 §1:

Two types have compatible type if their types are the same.

Therefore, long and int are not compatible, so the behavior is undefined, right?

However, in 6.5.2.2 §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.

If I correctly understand this paragraph, it means the argument x which is of type int is implicitly converted to long when the function is called. According to 6.3.1.3 §1:

When a value with integer type is converted to another integer type other than _Bool, if the value can be represented by the new type, it is unchanged.

As int has a lower rank than long, every int variable can be represented by a long variable. Therefore, the argument x can be converted into a long. Therefore, this is not undefined behavior.

Which interpretation of the standard is right? Is my code undefined behavior or not?

Answer 1

You provided irrelevant quotes relative to your code snippet. According to the same section (6.5.2.2 Function calls)

2 If the expression that denotes the called function has a type that includes a prototype, the number of arguments shall agree with the number of parameters. Each argument shall have a type such that its value may be assigned to an object with the unqualified version of the type of its corresponding parameter.

The function f has a prototype that is visible in the call expression

extern long f(long x);

and this assignment

int argument;
long parameter;
parameter = argument

is correct.

As for this quote

6 If the expression that denotes the called function has a type that does not include a prototype, the integer promotions are performed on each argument, and arguments that have type float are promoted to double. These are called the default argument promotions. If the number of arguments does not equal the number of parameters, the behavior is undefined. If the function is defined with a type that includes a prototype, and either the prototype ends with an ellipsis (, ...) or the types of the arguments after promotion are not compatible with the types of the parameters, the behavior is undefined. If the function is defined with a type that does not include a prototype, and the types of the arguments after promotion are not compatible with those of the parameters after promotion, the behavior is undefined, except for the following cases:

Then it means the following. The function calling expression does not see the function prototype. So the default argument promotions are performed. But somewhere else the function is defined with a function prototype and the promoted arguments are not compatible with function parameters. In this case you will have undefined behavior.

Here is a demonstrative program with undefined behavior related to a function call. The compiler can issue an error message.

#include <stdio.h>

void f();

int main(void) 
{
    short x = 10;
    
    f( x );
    
    return 0;
}

void f( char *s )
{
    printf( "s = %s\n", s );
}

or

#include <stdio.h>
#include <limits.h>

void f();

int main(void) 
{
    unsigned int x = UINT_MAX;
    
    f( x );
    
    return 0;
}

void f( int x )
{
    printf( "x = %hd\n", x );
}

For example in the last program the argument x in the call expression

f( x );

is promoted to the type unsigned int. But according to the function definition the function expects an argument of the type signed int and the passed value can not be stored in the type signed int. So the behavior is undefined. But your original example of a function call is not related to this quote.

Answer 2

The part "the arguments after promotion" is confusing, it refers to the default argument promotions defined earlier on in that same paragraph. Which doesn't apply here, since those rules are only used when there is no prototype or when we have variadic functions.

So "arguments after promotion are not compatible with the types of the parameters" applies to cases where you don't have a prototype, apply the default argument promotions (integer promotion in case of integers) and if the types are not compatible then, there is undefind behavior.

But since you have a prototype, forget about default argument promotion, instead continue to read the next part, C17 6.5.2.2/7 emphasis mine:

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.

Then we go read what's said about "as if by assignment", C17 6.5.16 emphasis mine:

the left operand has atomic, qualified, or unqualified arithmetic type, and the right has arithmetic type;

Both int and long are arithmetic types (and there are no qualifiers), this is a valid form of assignment. Further down in the same chapter:

The type of an assignment expression is the type the left operand would have after lvalue conversion.

So basically the code passing the parameter is equivalent to simple assignment:

int x;
long y;
y = x;

If we let the standard send us further on this merry chase, next look up lvalue conversion, C17 6.3.2.1:

...an lvalue that does not have array type is converted to the value stored in the designated object (and is no longer an lvalue); this is called lvalue conversion.

And then the actual conversion for integer types, C17 6.3.1.3:

When a value with integer type is converted to another integer type other than _Bool, if the value can be represented by the new type, it is unchanged.
Otherwise, if the new type is unsigned, the value is converted by repeatedly adding or subtracting one more than the maximum value that can be represented in the new type until the value is in the range of the new type.
Otherwise, the new type is signed and the value cannot be represented in it; either the result is implementation-defined or an implementation-defined signal is raised.

A long can always hold the value of an int, so the first sentence is the conversion that applies in this case.

Answer 3

Code is correct. IMO, the first interpretation does not a apply.

It is actually referring to calling a function without a prototype that is defined with a prototype:

long g(int x)
{
    return f(x);
}

// other translation unit
long f(long x) {
    return 0;
}

The code is defined only if f is called with single argument of type compatible with long.

Answer 4

In a typical C implementation where compilation units are processed independently, and the linker combines the separately-compiled object files and performs address relocation without attempting other optimization, there will be a specification, which today would commonly be called the Application Binary Interface, which describes among other things where/how code which calls a function should store the arguments, and where/how a function should expect to find arguments stored by its caller.

If a function attempts to retrieve arguments in a manner inconsistent with how its caller had stored them, the results are not likely to be meaningful. On the other hand, many platform ABIs describe behavior in terms of storage formats, rather than C data types. Thus, on e.g. a 32-bit ARM implementation where both int and long are 32-bit data types, a function that expects an int would be called in exactly the same fashion as one that expects a long or an int32_t. An ARM implementation that processes the code in different compilation units independently would thus not need to care if one compilation unit uses type int and another uses long, provided that both types have the same representation.

In general, one should make parameter/argument types match when practical, even on implementations that wouldn't care about such things, because it will make it easier for people to read the code and know what it's doing. In some situations, however, one may have different compilation units that expect to be given pointers to functions whose arguments are of different types with matching representations. In such situations, if one is using an implementation that processes compilation units separately, it may be possible to pass the address of a single function to code in both compilation units. Unfortunately, there is no means by which a programmer can indicate when a function call needs to be handled in a fashion consistent with the ABI, without regard for whether the Standard would define its behavior, and some aggressive optimizers make no attempt to meaningfully process constructs whose behavior would be defined by the ABI but not the Standard.