Was there any technological reason that C was designed to return only a single thing from a function?

Question

I'm asking specifically about C, not about other contemporary languages, but if the reason is "that's how B did it" or something please assume I'm talking about "in the lineage of C". I'm also aware that many if not all languages also adhere to the rule that only a single thing can be returned from a function, but again I'm interested mainly in why C does it.

A C function returns only a single thing, whether it be a fundamental data type or a pointer. I don't think there is any theoretical reason why it couldn't return more than one thing, and perhaps put all return values on the stack. So I'm wondering if there was a technological reason that the single return value rule was instated? If not, what was it?

**EDIT: by "single thing" I mean either a single variable of a fundamental data type or a pointer to something else. This is as opposed to returning a tuple, say:

(int x,char* y) = func(int a,double b);

Answer 1

The premise of the question is incorrect.

In the first edition of the C Programming Language book (thanks to @JonathanPotter), the authors mention the intent to support passing structs to functions and returning them from functions, along with assigning them to one another:

6.2 Structures and Functions

There are a number of restrictions on C structures. The essential rules are that the only operations that you can perform on a structure are take its address with &, and access one of its members. This implies that structures may not be assigned to or copied as a unit, and that they can not be passed to or returned from functions. (These restrictions will be removed in forthcoming versions.)

(note the parenthetical). This means that C was designed to return values of composite types from functions, but it was not considered essential to support them in the early releases of the compiler.

Indeed, while the C compiler in UNIX V5 does not compile the program below due to a bug (that is, it fails with an internal error message rather than a syntax error or a semantic error), and the V6 one says Unimplemented structure operation, the one available in BSD 2.9 happily compiles it correctly.

struct s { int a, b; };
struct s foo() {
    struct s r; 
    r.a = 5;
    r.b = 25;
    return r;
}
main() {
    struct s a;
    a = foo();
    printf("%d %d\n", a.a, a.b);
}

prints 5 25 as intended. Moreover, it does not happen by chance, as the assembly code contains an explicit copy of the function result into the memory location of the variable a, then its fields are pushed to the stack to be printed:

jsr     pc,_foo
mov     (r0),-12(r5)
mov     +2(r0),-10(r5)
mov     -10(r5),(sp)
mov     -12(r5),-(sp)

That is, the underlying C language mechanisms are sufficient to return arbitrarily complex structures. Writing functions returning ad-hoc tuples like

(int x,char* y) = func(int a,double b);

rather than values of predeclared types, would be an example of syntactic sugar.

Answer 2

There is obviously no technical reason why C could not have returned a "complex" type. Using your example, (int x,char* y) could have been a returned.

But at what cost? Please remember the state-of-the-art in 1972 where the computer that first ran the first C compiler was the PDP-11. The language was designed to be simple to implement and performant. Every feature you add to the language adds complexity and impacts performance. I'm sure they believed that having complex return types was not worth the cost.

As a C developer is it really so much more difficult to return a pointer to a struct or other complex data vs. the struct or data itself? Not really in my opinion.

Since there are other languages today that do return complex data that proves that C could have done it as well but the developers of the language either decided not to support that or (more likely in my opinion) didn't even consider it because it didn't fit with their vision for the language.

I think we sometimes assume that C was carefully designed from a detailed specification but that is certainly not the case. It was a quick-and-dirty project that was done to meet an immediate need for the research these guys were involved with.

Answer 3

On most platforms, expression evaluation would require having someplace reserved to put the result; simple compilers would always use the same CPU register or combination of registers for computations whose result is used for any purpose other than direct assignment to an register-qualified object.

If evaluation of an int expression always leaves the result in register 0, and the platform's process of handling function returns wouldn't disturb that register, then all the code generation for return X; would have to do, within an int function, would be to output code to compute the value of the associated expression in usual fashion (which would leave the value in R0) and follow that with a return instruction. An expression which calls a function that returns int would be generated by outputting a function call instruction and then assuming that the value of the function call expression had just been generated.

An essential thing to note about this approach for returning values is that the register used to hold the return value generally wouldn't be able to usefully hold anything else if it weren't used for that purpose, so returning a value in this fashion is "free".

While compilers fairly quickly added support for returning structures, this was often syntactic sugar for having callers create a structure on the stack and pass its address as an extra "hidden" argument, and then having a return statement in the called function copy data from whatever structure was used in the return statement to buffer supplied by the caller. Unlike simple-value returns, this approach would require allocating stack storage that otherwise wouldn't be allocated, and thus isn't "free".

Answer 4

Yes, prior to ANSI C, there was a technological reason. Valid code could corrupt the stack.

Prior to ANSI C, function declarations were optional. According to Bell Labs, if you called a function that had not yet been declared, the caller should assume that the return type was int. In their C Programmer's Handbook, p. 27, they warned that this could result in nonsensical results when the actual function definition had a different return type:

(I will paste a photoscan of that page here when I have time. It reads:)

Examples --

• Correct

extern double linfunc();
float y;
y = linfunc(3.05, 4.0, 1e-3)

The value of the function call is properly converted from double to float by the assignment to y.

• Incorrect

float x;
float y;
x = 3.05;
y = linfunc(x, 4, 1e-3)

This is wrong because types of arguments do not match declarations in definition, that is x is float not double, 4 is int not double. The result is that arguments passed on the stack are the wrong size and format, so that arguments taken off the stack by the quadfunc [sic, should read linfunc] are nonsense. There is no predictable return value. Also, unless the type of linfunc is declared, it is presumed to be type int. Thus even if the linfunc() did return a meaningful double, the value of the function call expression would be a nonsensical int value (e.g., upper half of a double).

---

The "single things" (technical name: scalars) that a function can return have the nice property that they can fit entirely within the register space of most processors. You don't need the stack; you just put the return value in one or more registers.

A compound object such as a struct or array might not fit within a processor's register space, requiring them to be placed on the stack. For this to properly work, the following must happen:

1. The caller must reserve space on the stack for the compound return value (in addition to the arguments also placed on the stack).
2. Control then transfers to the called function, which then reads the arguments and writes the compound return result to the stack.
3. Upon return, the caller then reads the return result from the stack, then discards the memory allocated to arguments and return value.

Getting back to pre-ANSI C, what happens if you call an undeclared function that intends to return a compound object?

1. The pre-ANSI behavior is for the caller to assume that int is being returned, thus no space (or the improper amount of space) is allocated on the stack for the return value.
2. Control is transferred to the called function. It tries to read arguments from the stack, which as noted above, might produce nonsense values. However, the called function will also try to store the compound result on the stack, which was not allocated by the caller. This will result in a corrupted stack.
3. With a corrupted stack, control may not return to the caller or its predecessors, crashing the program.

The easiest way to avoid this problem was to not allow compound objects as return values. Later compilers required function declarations, which is a better way of solving the problem.

Answer 5

Preface: There is no single, hard reason, but rather a series of good decisions.

Was there any technological reason that C was designed to return only a single thing from a function?

Sure. C is intended as simple language. Simple does not mean easy, but simple to implement with the least amount of language constructs possible.

For result passing the most simple thing to do is restricting it to a single value. This is what nearly all computers can do, what nearly all languages provide as minimum consensus and - maybe most important - what was already standard on the machines C was developed on: Returning a function's result in R0.

---

I don't think there is any theoretical reason why it couldn't return more than one thing,

You mean beside complexity? You mentioned the lineage of C. The eventually most important aspect of that evolution was to drop everything that is not absolutely required. The important distinction between a function and a (sub) procedure is that a function returns at least one value. The ability to return more than one value is not simple, thus unnecessary.

Likewise any syntax for multiple return values (like shown in your pseudo-code) would have added complexity to the compiler. This complexity would not really bring any benefit that couldn't be gained by other means - like passing pointers to variables, or, even better, using a structure and exchanging pointers.

and perhaps put all return values on the stack.

Three reasons:

1. Compatibility

   At that point it's important to remember that basic calling on the PDP-11 (*1) used to return any result value in R0. Sure, C could use parameter return on the stack. Except that would mean C programs could only call C functions/procedures. Any external function would need an assembly wrapper - or a compiler/linker extension to change parameter passing depending on the type of function called.

   C was not developed to write Unix, but to rewrite it. So linking to existing code was mandatory.

2. Runtime Memory

   Here lies another important simplification: Procedures are just functions that don't return anything - or better whose return value is ignored. If return value(s) would be handled using the stack, each call would have to allocate memory for that return value.

3. Execution Speed

   Each and every memory operation slows execution. Returning via stack means that any result value needs to be moved into that location first. And after returning from that location, storing a value at the end of a function in memory, that will be most likely be loaded right after returning again means two superfluous instructions to be executed without any gain.

4. Code Bloat

   Of course additional instructions also need additional code space. So returning a value via the stack means 2 instructions or (at least) 4 additional bytes.

All of this has to be seen in context of a PDP-11/20 with a main memory of only 64 KiB (256 KiB with MX11 - not sure if the one used by Ritchie had that).

---

*1 - The way PDP-11 subroutine calling is implemented is further complicated by how C implemented it.

Answer 6

C does support returning multiple values - using out parameters.

int arg_a;
int out_r;
f(arg_a, &out_r);

It seems obvious nowadays that a function consists of an argument list and a result, which then poses the question why there is no "result list".

The latest iterations of mainstream languages like C# do indeed have a result list, with accompanying syntax to define the result list in the function header, and to assign the results to multiple variables at the call site.

int arg_a = 1;
int arg_b = 2;
(int out_r, int out_s) = f(arg_a, arg_b);

However, back when C was first designed, it might not have seemed obvious why a function should even have a result as well as an argument list, when the argument list alone is capable of meeting all relevant needs.

In fact, a single pointer argument, passing the address of a struct, is capable of shuttling as many inputs and outputs as the programmer may find necessary.

struct f_args {
    int arg_a;
    int arg_b;
    int out_r;
    int out_s;
};

...

f_params fa;

fa.arg_a = 1;

...

f(&fa);

The answer to the question is really found in considering why a single pointer argument is not generally considered enough.

Computational efficiency

The first issue is computational efficiency. Passing multiple values in registers is more efficient than just passing a pointer in a register (or on the stack) and letting the callee unpack the contents.

One of the benefits of C at the time of its conception, compared to assembly, was that the compiler was capable of selecting and using registers appropriately for the purpose of shuttling values into and out of functions - using the full complement of registers furnished by whatever hardware was in use - without the programmer being hassled by the task of register selection as they would be when writing assembly.

Therefore, passing values in as individual items (rather than as a pointer to a struct) has a real bearing on efficiency.

Typical balance of arguments and resultants/composition into expressions

It's also common in practice that functions take multiple arguments but return a single value. All basic arithmetical operators take two arguments and return one value - dyadic and monovalent. Standard mathematical expressions also rely on all evaluations being monovalent.

Modelling this traditional mathematical style (without attempting to innovate it), and the de facto reality that many functions have multiple inputs but only one output, is therefore what strongly justifies the specific configuration of a multi-value argument list, and a single return - polyadic and monovalent.

Again to compare with assembly, expressions were a big jump in functionality - and there must be at least one return value (as distinct from merely an out parameter) to allow composition of functions as part of expressions.

Syntactic ease

The practice of defining the argument list inline with the header (as opposed to defining a struct), and of composing values together inline as part of the call (as opposed to assigning values into a struct as a preparatory step before a call), has been found to be a good usability feature.

Although the inline composition has always been present in C, the ANSI C syntax for actually defining a function (and its arguments and argument types), does not correspond with the original style in K&R C.

A style of function definition that nowadays seems standard across many programming languages, was not a settled question at the time C was originally designed.

Mathematics uses functions, but it had no corresponding practice or syntax for defining type constraints (or even any explicit concept of "type" as programmers know it), so there was additional design work required on the syntax.

Conclusion

It's at least for the above reasons why C came to have a polyadic-monovalent style of function, as opposed to either the bare bones of what is necessary (which is one argument and no return value - monadic and nonvalent), or some other style.

The existence of the return value at all, is primarily driven by its compelling use as part of expressions. Multiple return values do not exist, because how to integrate them usefully into expressions is not even clear today, and certainly wasn't on the agenda in 1972.

Certainly, modern functional languages have operators which can select individual values from amongst multiple results of a previous stage, but there's often a massive loss of explicitness and obviousness.

Meanwhile, I suspect in C# that the predominant use of multiple return values, is not for use within expressions - in other words, multiple returns are used for completely different (and far less important) purposes than what single returns are typically used for.

And the long-time existence of a multi-value argument list (as opposed to just a single value), besides aligning with the existing mathematical practice, is primarily because it saves the hassle of always defining and assigning a separate structure, and because it is capable of catering to the need for multiple output parameters as well as multiple inputs.

Answer 7

Is simplicity a technological reason?

Usually, C functions parameters are pushed into the stack before call and then flushed after by the calling procedure (PASCAL is different, the callee pops its own parameters). The stack is one-way.

If possible, the return value is passed in a register, "accumulator", R0, EAX or their floating-point equivalents.

Answer 8

There's also nomenclature: C calls these functions, like the mathematical concept of a function. Mathematical functions return a single type of value even if that's a tuple or something more complicated. So functions returning a single thing matches the metaphor of what a computer operator would have expected out of the f(x) notation used. If they were 'subroutines' maybe they would have had no return code at all and only in-parameters and out-parameters.

Answer 9

DrSheldon's answer is right in that implicit function declarations require a canonicalized way to return a fixed amount of values, which was set to one. And this is a technological reason, albeit on the language level. He has my upvote for it.

As a matter of fact, it is just as easy to define an ABI that allows for arbitrary return values as it is to allow for arbitrary parameters. The available mechanisms are exactly the same: First you can define some registers to hold the first few values, and just as larger values are passed on the stack, the caller can reserve stack space to return larger values.

As such, I believe that the real reason for not allowing more than one return value is the same as for modern languages: Virtually all languages use the notion that a function call has a value just like a variable name or some expression does. C is no exception to this. If you have a function that returns multiple values, you are only able to use a single one of these values implicitly, or the tuple of return values as a whole.

Today, some languages have adopted tuple unpacking in an assignment to work around this problem. But the problem persists: Where you can use a single return value right in the middle of any odd expression, you must first assign multiple return values to something in a tuple assignment. Needless to say, C does not have tuples. It has struct, and you can indeed define a struct for a function return. However, you need to give that struct a name, both for the type and the variable to which you assign the function result. It is doable, but requires some boilerplate code.

So, the real technical reason to not implement multiple return values has nothing to do with the hardware. It is a problem of language design that persists today, and even the most modern languages can only ever work around it. These workarounds introduce complexities into the compiler that must have looked quite unnecessary, and most certainly not simple, to the people who developed C.

Answer 10

It is worth noting that C is a low level procedural language and does not really support Object Oriented programming.

This seems odd seeing that all the children languages of big-daddy-C brought OOP to the masses.

C was designed to deal specifically with hardware at a low level. It does this exceptionally well, but a lot of the niceties we have grown used to are absent in its implementation.