In C, why limit || and && to evaluate to booleans?

Question

In some languages, e.g. Ruby, an expression like:

val = call_fn() || DEFAULT_VAL;

will set val to the results of call_fn() if it is truthy (non-zero, non-NULL, etc), or to DEFAULT_VAL otherwise. This can be really useful.

In C, the result of the || operator is always a boolean value (1 or 0).

Is there a strong argument for C limiting the result to a boolean value (other than tradition)?

Addendum

Using some gnu extensions, a macro that approximates the behavior I'm looking for could be written as:

#define OP_OR(a, b)                                 \
    ({                                              \
        __typeof__(a) _a = (a);                     \
        _a ? _a : b                                 \
    })

This evaluates to a iff it is truthy (i.e. non-0 for numeric values, non-NULL for pointers, not '\0' for chars), otherwise it evaluates to b. The __typeof__ line guarantees that a is evaluated exactly once.

Answer 1

Boolean types and Boolean expressions are the crux of the logical formalism and the latter is ubiquitous in programming. C was lacking them in the beginning, yet another design flaw of this language (took like twenty years to be fixed!).

Tinkering a boolean type with integers is not just a conceptual mistake, it is a source of problems, such as comparisons not behaving as expected.

I don't know about the semantics of && in Ruby, but presumably it has to make an asymmetric choice between the two values in case of two non-zeroes.

This said, the ternary ? operator allows you constructs like

val= call_fn();
val= val != 0 ? val : DEFAULT_VAL;

---

Independently of this answer, I don't see the trick

val = call_fn() || DEFAULT_VAL;

with a good eye, as it forces you to reserve the value 0 to somehow indicate "do not use this returned value" and cannot work with functions that can legitimately return 0. I'd prefer a function that returns DEFAULT_VAL directly.

Answer 2

An operator can be described in terms of three things:

• The accepted range of values (type) of each of its operands
• Its behaviour
• The possible values (type) of its result

The simplest "or" operator is defined as having two operands and a result all with values "true" or "false", i.e. a "boolean" type. With such a definition, the result of 42 || 69 would be undefined, just as the value of "hello" / "world" is undefined. The result of any valid pair of operands would always be either "true" or "false", never another value.

C evolved gradually from a language called B, which had no distinction between types, so all operators were defined over the range of binary values that could be contained in a particular memory location. For operators that would normally require "true" and "false" values, B defined a value of all zero bits as "false", and any other value as "true". This carried over into early versions of C, where the || operator was defined† for any pair of integers, with the same rules. However, the result was still defined as only having two possibilities: 0 for false, 1 for true.

Other languages have generalised the operator further, and said that the range of results also has more than two values: the representation of "false" is fixed, but "true" is replaced by a direct copy of one of the inputs.

We can speculate why early versions of C didn't generalise the result in that way:

• A fixed result may be more efficient to implement than a memory copy
• The possibility simply didn't occur to the language's designers at the time

More clearly, we can answer why C didn't later adopt a different definition: it could break existing code. Consider the following snippet of code:

c = a || b;
z = x || y;
switch ( c + z ) {
    case 2: ... // both c and z are true
    case 1: ... // one or other is true
    case 0: ... // neither is true
}

This code relies on the guaranteed range of outputs from the || operator. If a || b evaluated to 2, the wrong branch would be entered; if it evaluated to 42, none of the branches would be entered.

In general, this is similar to the rules around covariance and contravariance:

• It is safe to widen the input, e.g. to define a result for "hello" / "world" if that was previously forbidden or Undefined Behaviour
• It is safe to restrict the output more narrowly than previously guaranteed, e.g. to add a guarantee that a certain operator will never evaluate to NaN
• It is not safe to narrow the input, and forbid code that was previously acceptable
• It is not safe to widen the output, and produce values that code was not previously expecting

---

† - According to Dennis Ritchie's description of the language's development, B only had the bitwise or operator, |. That gives the same result as a boolean or with the above definition of "true" and "false", because 0 | 0 yields 0, and any other operands yield a non-zero result. The downside is that you need to examine both operands to produce a result, whereas a boolean or can "short-circuit" if the first argument is true. The separate || operator was added to early C as a replacement for a special case that allowed | to short-circuit in conditional statements, along with even more complex rules for &.

Answer 3

Edit: After re-reading the question and wovano's comment I think my answer below misses the point because the suggestion to return the non-zero operand or zero if there isn't any would not be overly complicated or abstract if the operands stayed restricted to scalar types. I let the answer stand because I still think it's a good text ;-).

---

The reason is that C, by design, is a really simple language that provides operations closely aligned with what machine code of machines like the PDP11 offered. You posted the question in the computer science stack exchange, but computer science is not what C was designed for or from which it came. C is the creation of engineers writing an operating system and hitting a limit of what was maintainable and portable in assembler. They were in a unique spot because they had the insight, skill, time and attitude to backtrace and write a tool for that: C. They seized the day and, one may say without exaggeration, changed the world.

C is a language created to solve an engineering problem.

Because of the memory and computing limits the language had to be dirt simple, so that even a simple compiler could produce good code.

The language had to be closely aligned with what the machine offered.

While I'm not familiar with PDP11 machine code I bet you there is a test for zero, an AND operation on registers, and a conditional jump. On that level there is no concept of a boolean; everything is integers.

This is what C mimics. The machine operation has a C equivalent which makes it totally obvious what the compiler would produce. (The same "everything is an integer" concept was used for pointers.)

In order to appreciate the differences of C's "engineering" approach to a computer science approach, have a look at Algol68. That is a (seriously) great language designed without concerns for the resources the compiler or code would need. It is also instructive to compare the language descriptions^1,2, a contrast which more than highlights the pragmatic approach of the C creators.

As others remarked, a shortcut for selective evaluation dependent on a condition exists with the ternary ?: which is about as complicated as you get with C.

---

¹ For Algol68: https://www.softwarepreservation.org/projects/ALGOL/report/Algol68_revised_report-AB.pdf

² For C: The first edition of Kernighan/Ritchie: The C Programming Language

Answer 4

The operand of if, while, etc. isn't limited to integer types, but will also work with floating-point or pointer types. For a value x of any integer, floating-point, or pointer type, if(x) is equivalent to if ((x) != 0), with the literal zero being interpreted as a value of x's type. Making a construct like if ((x) || (y)) work with any combination values x and y that could be used as conditionals individually, without regard for whether the types would be compatible with each other, would require that the || operator be capable of yield a value of a type that was incompatible with at least one operand.

Note that the behavior of a construct like:

double d = 0.125;
char *p = "Hello there!";

if (d || p)
  printf("The values are %5.3f, %s!", d, p);

is quite different from what it would be if the condition were written as

if ((int)d || (int)p)

The value of (int)d would be zero, even though d is regarded as non-zero by the || operator, and the while the value of (int)p probably wouldn't be zero, there are some platforms where pointers are longer than integers, and where the value of that expression might be zero by chance.

While there probably would have been no difficulty saying that the && operator be syntactic sugar for leftOp ? rightOp : 0, I can't think of any nice way of describing the behavior of || that would allow it to be used in scenarios where the types of the operands differ, but wouldn't introduce behavioral inconsistencies in such cases.

Given that C is in fact generally parsed outside-in, and efficient processing of || and && operators would require knowing whether they are being used as part of a top-level conditional construct, it might have been practical to specify that when the result of || or && is coerced to a "conditional test", the operands would be likewise coerced, and that the operands of those operators must be integers in all other cases. A similar principle could also have been usefully applied to constructs like uint1 = ushort1*ushort2; on implementations that don't use quiet-wraparound two's-complement semantics: since the result of the multiplication will be coerced to unsigned int, the operands should be likewise coerced and then multiplied as that type. Unfortunately, this kind of thing is easier to do than to formally specify, and thus language specs make no accommodation for it.

Answer 5

The || and && operators in Ruby are closer to basic process algebra composition operators than to boolean connectives. The languages just happen to use the same symbols for these two different sorts of operators due to the lack of glyphs on the keyboard.

Keeping this in mind there are important distinctions between the || operator in Ruby and alternative composition. One such distinction is that || in Ruby is not commutative.

The analogy stands in the sense that in basic process algebra one can simulate boolean algebra but not vice versa.

Coming now to the original question. The C programming language exists as a language on its own and not as a subset of C++ precisely because it has a relatively clean semantics and it is relatively easy to tell how an expression is to be evaluated. If we instead allow things like -1L || 4U or 0.0 || 42 with numeric type promotion, this would make compilation results less predictable.

Finally as it was mentioned before the ternary conditional operator x>0 ? x : y in C would be an almost perfect drop in replacement for the proposed numeric choice operator x || y.

Answer 6

In many Lisp dialects, there is usually an or operator which returns the leftmost value that is not nil, and stops evaluating the rest.

GNU C does have an operator which evaluates A, and returns A if A is nonzero, otherwise B, namely: A ?: B.

Why, in C, we don't want || to have this semantics because C is statically typed in a particular way. The expression A || B has to have a type. The type has to be derived from the types of A and B. If it has the semantics of evaluating either to A or B, that then requires A and B to be compatible. They have to have the same type, or else one has to convert to the type of the other.

Suppose P, Q and R are pointers to different object types, and thus incompatible. You cannot write P || Q || R under this semantics; it violates a type constraint. Under the C semantics of || as they are, the above is allowed: it yields true if any of the three pointers is non-null.

In terms of type theory, such an operator calls for a sum type: its type wants to be the sum type of the constituent expressions. Thus if we have W || G where W is a Widget and G is a Grommet, the resulting type is Widget | Grommet: a type that can be either.

This is why the or operator works in Lisp dialects, and its equivalentin other dynamic langauges: they are dynamically typed, and so every value is potentially a sum type of everything, making the type problem go away into run-time. (or W G) has no problem yielding a value that is either a Widget or a Gadget, because that dynamism is already everywhere.

Answer 7

One possible reason is that bitwise operations on relations would give the wrong results. For example, the code

if ((printf( "hello, %s, it's", higher_power ) == 16) &
    (printf( " me, %s\n", luser ) <= 15)) { 

would evaluate to false if both conditions are met, if logical operations returned the value of one of their operands, and not execute the body of the loop! And the programmer could not change & to && without potentially short-circuiting the second function call, which has side-effects. When both results are constrained to be either 1 or 0, the above works.

This doesn’t literally use && and ||; I picked a more natural example using comparison relations. The principle is exactly the same. But, in B, the predecessor language to C, there were no || or && operators, and everyone used & and | instead. This worked because false was always 0 and true was always ~0.

The choice of 1 as TRUE in C, rather than ~0, also means that the representation of TRUE is the same for every integral type, and can round-trip convert with floating-point, so treating boolean results as int values could just work. If x == y returned 0xFFFFU on a DEC PDP-11 when the types of X and Y were unsigned int, but 0xFFFFFFFFUL when the types were unsigned long int, suddenly any subexpression that widened the result of a 16-bit unsigned boolean true to unsigned long int width would have produced 0x0000FFFFUL and caused these logical operations to fail on the upper word. (This had not been an issue for B, as it was an untyped language.) With no special Boolean type, automatic conversion to and from a float would have been an issue as well. Later, although we know this was unfortunately not something on their minds at the time, the default type promotion rules would have caused even more bugs in the 16-to-32-bit transition. Migrating this code to a 32-bit VAX would have caused all the boolean operations on int values to suddenly produce 0xFFFFFFFF, not 0xFFFF.

The choice of 1 as the value of Boolean true also follows the precedent of Algol, a trendy language in the early ’70s.

The above is my own speculation. Dennis Ritchie would later write about the creation of separate logical operators: What he had to say about it in his own words:

Rapid changes continued after the language had been named, for example the introduction of the && and || operators. In BCPL and B, the evaluation of expressions depends on context: within if and other conditional statements that compare an expression's value with zero, these languages place a special interpretation on the and (&) and or (|) operators. In ordinary contexts, they operate bitwise, but in the B statement

if (e1 & e2) ...

the compiler must evaluate e1 and if it is non-zero, evaluate e2, and if it too is non-zero, elaborate the statement dependent on the if. The requirement descends recursively on & and | operators within e1 and e2. The short-circuit semantics of the Boolean operators in such `truth-value' context seemed desirable, but the overloading of the operators was difficult to explain and use. At the suggestion of Alan Snyder, I introduced the && and || operators to make the mechanism more explicit.

Their tardy introduction explains an infelicity of C's precedence rules. In B one writes

if (a==b & c) ...

to check whether a equals b and c is non-zero; in such a conditional expression it is better that & have lower precedence than ==. In converting from B to C, one wants to replace & by && in such a statement; to make the conversion less painful, we decided to keep the precedence of the & operator the same relative to ==, and merely split the precedence of && slightly from &. Today, it seems that it would have been preferable to move the relative precedences of & and ==, and thereby simplify a common C idiom: to test a masked value against another value, one must write

if ((a&mask) == b) ...

where the inner parentheses are required but easily forgotten.

In Section 2.6 of The C Programming Language, Kernighan and Ritchie specify:

By definition, the numeric value of a relational or logical expression is 1 if the relation is true, and 0 if the relation is false.

Since then, C and all of its successor languages have been boxed in by backward compatibility.

Postscript

Since one commenter requested an example of code involving literal && and || that breaks when a boolean sub-expression either takes the value of its truthy argument, as you ask about, or promotes from 0xFFFFU to 0x0000FFFFUL, as it would have if Ritchie et al. had represented TRUE as in B and given C the same implicit-promotion rules, here is an arbitrary one.

(function_returning_unsigned_int() && function_returning_signed_int()) ^
(unsigned_long_value || function_call()) /* 0x0000FFFFUL ^ 0xFFFFFFFFUL is truthy. */

I make no claim about how likely it is to occur, but at the time, Ritchie, Kernighan and Thompson had a large codebase that always used bitwise operators on logical expressions.

Answer 8

I think the direct answer is, "No, there is not a strong argument."

It seems to me that the functionality you're describing would have worked overall pretty consistently in C (if introduced at the start), and if you had been able to make your case to the creators of C at the time they might well have at least considered it on the strength of your arguments (if you had some good examples for them of why "this can be really useful").

Answer 9

The question states

"In C, the result of the || operator is always a boolean."

This is misleading. The result of both || and && is type int. The value of the int is either 0 or 1.

Note that the C11 standard introduced type _Bool, and the upcoming C23 standard goes further with primitive type bool. However, in neither case is the type of || or && changed. It is still int.

This statement should always test true even if the size of an int is different from the size of a boolean:

sizeof(A || B) == sizeof(int)

Anyway, the answer to the question is that || means "or" and is the C version of "or" in earlier languages like Algol. It was never intended to mean "else". The rule that says the right side is not evaluated if the left side is true was intended as an efficiency plus an convenient way to guard the second part (such as "if (i > n || a[i] == 0)" if a[n] is the last element of the array).

Brendan.

Answer 10

If I understand the use here correctly it's because C languages already have another operator for that: ?:

So in C languages

val = call_fn() || DEFAULT_VAL;

would be written as

val = call_fn() ? call_fn() : DEFAULT_VAL;

or

tmp = call_fn();
val = tmp ? tmp : DEFAULT_VAL;

Depending on constness of call_fn().

The || and && operators are meant exclusively for boolean logic in C and so they condense to only the minimum definition of true and false for their output.