Engineering/Backend

How C Evaluates Expressions

Isaac S. Lee 2026. 7. 27. 21:10

C operators look simple at first.

Addition uses +, division uses /, equality uses ==, and conditions are combined with &&. Anyone who has worked with another programming language will recognize most of these symbols.

The difficulty begins when a seemingly ordinary expression produces an unexpected result.

A value assigned to a double may still lose its fractional part. A comparison may claim that -1 is not less than 1. A range check written like a mathematical inequality may evaluate to true for a value far outside the intended range. A missing pair of parentheses in a bitmask check may silently change the meaning of the entire condition.

It is tempting to treat these cases as isolated quirks of C. That approach quickly turns into a collection of rules to memorize.

There is a better way to understand them.

C does not evaluate an expression based only on the operator that appears in the source code. It also considers the types of the operands, applies promotions and conversions when necessary, and then performs the operation according to the converted types. Operator precedence determines how the expression is grouped, while evaluation order determines when its individual parts actually run.

Once these ideas are connected, many of C’s most surprising results stop looking arbitrary.

This article follows that process from beginning to end. The goal is not merely to predict output, but to understand how expression rules affect correctness, portability, security, and readability in real programs.

A type is more than a storage size

Types are often introduced as containers of different sizes.

A char stores a small integer, an int stores an ordinary integer, and a double stores a floating-point number. That explanation is useful at the beginning, but it is not enough to reason about expressions.

A type also determines:

  • which values can be represented
  • whether negative values are allowed
  • whether arithmetic uses integer or floating-point rules
  • how a value is converted when combined with another type
  • what happens when a calculation exceeds the representable range
  • how bitwise and shift operations behave

C provides several standard integer types:

char
signed char
unsigned char

short
unsigned short

int
unsigned int

long
unsigned long

long long
unsigned long long

The main floating-point types are:

float
double
long double

The exact sizes of these types are not identical on every implementation. An int is commonly 32 bits on modern desktop and server systems, but the C language does not require that size everywhere.

When an exact width matters, such as in a file format or network protocol, the types in <stdint.h> can make the intended representation clearer.

#include <stdint.h>

int32_t temperature;
uint32_t packet_size;

Numeric literals have types as well.

10      // int
10U     // unsigned int
10L     // long
10LL    // long long

1.0     // double
1.0f    // float
1.0L    // long double

Those suffixes are not decorative. A single U or L can change the conversions applied to the rest of an expression.

In C, a number never participates in a calculation as a value alone. Its type travels with it.

Assigning to a double does not make the earlier calculation floating-point

One of the most common examples is integer division.

Consider the following code:

int completed = 7;
int total = 2;

double progress = completed / total;

Because progress is a double, it may seem reasonable to expect 3.5.

The stored value is actually 3.0.

The reason is that calculation and assignment happen at different stages.

At the moment completed / total is evaluated, both operands have type int. C therefore performs integer division.

7 / 2 = 3

Only after that result has been produced is the integer 3 converted to double.

3 → 3.0

The fractional part was not lost during assignment. It had already been discarded by the integer division.

To request floating-point division, at least one operand must be floating-point before the division occurs.

double progress =
    (double)completed / total;

Now completed becomes 7.0, and total is converted to 2.0 for the operation.

7.0 / 2.0 = 3.5

The position of a cast matters as well.

double first = (double)(7 / 2);
double second = (double)7 / 2;

The first expression performs integer division before applying the cast.

7 / 2
→ 3

(double)3
→ 3.0

The second expression converts an operand before the division.

(double)7
→ 7.0

7.0 / 2.0
→ 3.5

The results are therefore:

first  = 3.0
second = 3.5

This distinction matters in production code, especially when calculating rates, averages, percentages, or monitoring metrics.

double success_rate =
    success_count / request_count;

If both counters are integers, the result may collapse to values such as 0.0 or 1.0.

The intended calculation should make the floating-point conversion explicit.

double success_rate =
    (double)success_count / request_count;

When reading an expression, the destination type is not the first thing to inspect. The important question is what types the operands have when the operation begins.

Small integer types are often promoted before arithmetic

A variable declared as char or short does not necessarily participate in arithmetic using that exact type.

C applies integer promotions to small integer types before many operations.

Consider this example:

unsigned char left = 200;
unsigned char right = 50;

int result = left + right;

It may appear that the addition happens inside the range of unsigned char.

On many systems, however, int can represent every value of unsigned char. Both operands are therefore promoted to intbefore the addition.

(unsigned char)200 → (int)200
(unsigned char)50  → (int)50

200 + 50 = 250

The arithmetic is performed as int arithmetic, not as unsigned char arithmetic.

The same rule affects bitwise operations.

unsigned char value = 0x0F;
int inverted = ~value;

Before applying ~, the value is promoted to int.

On a common system with a 32-bit int, the operation is conceptually closer to this:

value
00000000 00000000 00000000 00001111

~value
11111111 11111111 11111111 11110000

It is not merely the 8-bit value 11110000.

When only the lowest eight bits are desired, the result should be narrowed or masked deliberately.

unsigned char inverted =
    (unsigned char)~value;

Or:

unsigned int inverted =
    (~value) & 0xFFU;

A useful consequence follows from this rule:

The declared type of a variable and the type of an intermediate expression are not always the same.

Two char values can produce an int expression. That difference matters whenever overflow, bit patterns, or later conversions are involved.

Mixed arithmetic uses a common type

When operands of different arithmetic types appear in the same operation, C first converts them to a common type.

int count = 3;
double rate = 1.5;

double result = count * rate;

The integer count is converted to double before multiplication.

3 → 3.0
3.0 × 1.5 = 4.5

These rules are known as the usual arithmetic conversions.

When floating-point types are involved, the lower-ranked operand is generally converted to the higher-ranked floating-point type.

int + double
→ convert int to double

float + double
→ convert float to double

double + long double
→ convert double to long double

Integer conversions are more subtle because signedness and conversion rank both matter.

The important practical rules are:

  • operands with the same signedness are usually converted to the type with the higher rank
  • signed and unsigned operands may require a range comparison
  • the signed operand may be converted to an unsigned type
  • a negative value converted to an unsigned type becomes a large nonnegative value

That final case is responsible for some of the most surprising comparisons in C.

Why -1 < 1U can be false

These two comparisons look almost identical:

printf("%d\n", -1 < 1);
printf("%d\n", -1 < 1U);

The first comparison is true.

-1 < 1
→ 1

Both operands are int.

In the second expression, however, 1U has type unsigned int.

-1 < 1U

Before the comparison, the operands are converted to compatible types. On a common 32-bit implementation, -1 is converted to unsigned int.

That produces a value similar to:

-1 → 4294967295U

The comparison is therefore effectively:

4294967295U < 1U
→ false

The result is 0.

This behavior appears in real code when signed integers are mixed with size_t, which is an unsigned integer type.

int index = -1;
size_t length = 10;

if (index < length) {
    /* ... */
}

During the comparison, index may be converted to a large unsigned value.

In this particular example, the condition becomes false, which may appear harmless. The same mismatch becomes more dangerous when the values are used in subtraction, allocation sizes, offsets, or pointer calculations.

Signed and unsigned values should not be mixed casually. The values may look reasonable in isolation while the conversion changes their meaning immediately before the operation.

An explicit cast expresses intent, but it does not guarantee safety

A cast can make an intended conversion clear.

double ratio =
    (double)completed / total;

Here, the cast communicates that floating-point division is required.

But a cast is not a general-purpose safety mechanism.

int value = 300;

unsigned char narrowed =
    (unsigned char)value;

If the destination type cannot represent 300, information is lost.

Converting a floating-point value to an integer discards the fractional part toward zero.

int first = (int)3.9;
int second = (int)-3.9;

The results are:

first  = 3
second = -3

Narrowing a wider integer type has similar risks.

int count = get_large_count();
short small_count = (short)count;

The cast may silence a compiler warning, but it does not prove that count fits inside a short.

A safer version checks the range first.

#include <limits.h>

if (count < SHRT_MIN ||
    count > SHRT_MAX) {
    /* handle an out-of-range value */
} else {
    short small_count =
        (short)count;
}

A good cast documents a conversion whose consequences have already been considered.

A bad cast merely hides evidence that the types may not match the data.

Integer overflow is not just a calculation error

Integer types have finite ranges.

Consider the following code:

int value = INT_MAX;
value = value + 1;

It may seem natural to assume that the value wraps around to INT_MIN.

C does not guarantee that behavior for signed integers.

Signed integer overflow causes undefined behavior.

This matters because compilers are allowed to optimize under the assumption that undefined behavior does not occur. The result may be more surprising than a single wrapped value. Branches, comparisons, or entire calculations may be transformed based on assumptions that no overflow is possible.

Unsigned integer arithmetic is different.

unsigned int value = UINT_MAX;
value = value + 1U;

The result is defined to wrap to zero.

UINT_MAX + 1U
→ 0

This modular behavior is useful in hashes, checksums, ring counters, and bit-oriented algorithms.

Defined behavior, however, is not automatically safe behavior.

Consider an allocation-size calculation:

size_t bytes =
    count * sizeof(struct Item);

struct Item *items =
    malloc(bytes);

Because size_t is unsigned, an overflowing multiplication can wrap to a much smaller value.

The program may then allocate less memory than required and later write beyond the allocation.

A defensive check can be performed before multiplication.

if (count >
    SIZE_MAX / sizeof(struct Item)) {
    /* handle size overflow */
}

size_t bytes =
    count * sizeof(struct Item);

Expression rules are therefore directly connected to memory safety. Integer overflow is not merely a puzzle about numeric output. In allocation code, parsers, network protocols, and file processing, it can become a security vulnerability.

Relational operators cannot be chained like mathematical inequalities

C provides the usual relational operators:

<
<=
>
>=

Equality operators are:

==
!=

Their result is an int: 1 for true and 0 for false.

int first = 5 < 10;
int second = 5 == 10;

The values are:

first  = 1
second = 0

Because comparison results are ordinary integer values, mathematical-looking range checks can behave unexpectedly.

int value = 20;

if (0 < value < 10) {
    printf("inside\n");
}

C does not interpret this as one continuous inequality.

The expression groups from left to right:

(0 < value) < 10

With value equal to 20, the first comparison is true.

0 < 20
→ 1

The program then compares that result with 10.

1 < 10
→ 1

The overall condition is true even though 20 is outside the intended range.

The correct form uses two comparisons joined by logical AND.

if (0 < value &&
    value < 10) {
    printf("inside\n");
}

C’s comparison operators resemble mathematical notation, but each comparison remains a separate expression whose result may participate in another operation.

Logical operators evaluate truth, not magnitude

C treats zero as false and any nonzero value as true.

The logical operators are:

!   // logical NOT
&&  // logical AND
||  // logical OR

Their results are always 0 or 1.

printf("%d\n", !0);
printf("%d\n", !5);
printf("%d\n", 3 && 7);
printf("%d\n", 0 || -2);

The output is:

1
0
1
1

The result of 3 && 7 is not 7.

The operator checks only whether both operands are nonzero.

3 → true
7 → true

true && true
→ 1

This is different from bitwise AND.

printf("%d\n", 6 && 3);
printf("%d\n", 6 & 3);

Logical AND produces 1.

6 && 3
→ 1

Bitwise AND compares individual bits.

6 = 110
3 = 011
    ---
    010 = 2

The output is:

1
2

The pairs && and &, || and |, and ! and ~ look related, but they solve different problems.

Logical operators build conditions. Bitwise operators manipulate integer representations.

Short-circuit evaluation can make conditions safe

Logical AND and logical OR do not always evaluate both operands.

For:

left && right

if left is false, the entire expression is false and right is not evaluated.

For:

left || right

if left is true, the entire expression is true and right is not evaluated.

This is called short-circuit evaluation.

It is often used to express a safe order of checks.

if (pointer != NULL &&
    *pointer > 0) {
    /* ... */
}

If pointer is NULL, the second condition is skipped. The null pointer is never dereferenced.

The same pattern protects array access.

if (index < length &&
    values[index] > 0) {
    /* ... */
}

The element is read only after the bounds check succeeds.

It can also prevent division by zero.

if (divisor != 0 &&
    value / divisor > 10) {
    /* ... */
}

Short-circuit evaluation is not merely a performance detail. It is part of how safe conditions are constructed in C.

It can still be overused.

ready || initialize();

This calls initialize() only when ready is false. The behavior is valid, but the side effect is hidden inside a logical expression.

A more explicit version is easier to read.

if (!ready) {
    initialize();
}

The shortest expression is not always the clearest expression, especially when function calls or state changes are involved.

Bitwise operations are useful for flags and compact state

C provides several bitwise operators:

&
|
^
~
<<
>>

A common use is representing multiple flags inside one integer.

#define FLAG_READ   0x01U
#define FLAG_WRITE  0x02U
#define FLAG_EXEC   0x04U

Each flag occupies a separate bit.

FLAG_READ  = 0001
FLAG_WRITE = 0010
FLAG_EXEC  = 0100

Two flags can be combined with bitwise OR.

unsigned int flags =
    FLAG_READ | FLAG_WRITE;

0001
0010
----
0011

A flag can be enabled with OR:

flags |= FLAG_EXEC;

It can be cleared with AND and bitwise NOT:

flags &= ~FLAG_WRITE;

It can be toggled with XOR:

flags ^= FLAG_WRITE;

A flag is tested with bitwise AND.

if ((flags & FLAG_WRITE) != 0U) {
    /* write permission is enabled */
}

This pattern is used in operating-system permissions, device states, protocol fields, feature options, and many low-level APIs.

Operator precedence can silently change a bitmask test

This condition looks plausible:

if (flags & MASK == 0U) {
    /* ... */
}

Many readers mentally interpret it as:

if ((flags & MASK) == 0U) {
    /* ... */
}

That is not how C groups the expression.

Equality has higher precedence than bitwise AND, so the actual grouping is:

if (flags & (MASK == 0U)) {
    /* ... */
}

If MASK is not zero, the comparison produces 0.

MASK == 0U
→ 0

The remaining expression becomes:

flags & 0U
→ 0U

The intended test must use explicit parentheses.

if ((flags & MASK) == 0U) {
    /* the masked bits are not set */
}

Or:

if ((flags & MASK) != 0U) {
    /* at least one masked bit is set */
}

Parentheses are not only for readers who have forgotten the precedence table.

They communicate which operations form one conceptual unit.

In code reviews, that clarity is often more valuable than saving two characters.

A simplified precedence order for common operators is shown below.

CategoryOperators

Postfix x++, x--, a[i], f()
Unary !, ~, *, &, ++x, (type)
Multiplicative *, /, %
Additive +, -
Shift <<, >>
Relational <, <=, >, >=
Equality ==, !=
Bitwise AND &
Bitwise XOR ^
Bitwise OR `
Logical AND &&
Logical OR `
Conditional ?:
Assignment =, +=, -=, &=
Comma ,

Memorizing the entire table is less valuable than recognizing risky combinations and using parentheses when the intended grouping is not immediately obvious.

Precedence and execution order are different concepts

Operator precedence determines grouping.

2 + 3 * 4

The multiplication is grouped first.

2 + (3 * 4)

That does not mean precedence fully determines the order in which every subexpression is evaluated.

Consider:

first() + second() * third()

Its grouping is clear.

first() + (second() * third())

The language does not necessarily require those three function calls to occur in the order they appear in the source code.

Function arguments have a similar issue.

process(load_first(), load_second());

Code should not depend on load_first() being called before load_second().

This becomes dangerous when multiple subexpressions modify the same object.

process(index++, index++);

The modification order is not safely defined for this use. The expression can invoke undefined behavior.

The operations should be separated.

int first_index = index++;
int second_index = index++;

process(first_index, second_index);

Adding parentheses does not create an execution order.

(first()) + (second())

The parentheses clarify grouping, but they do not guarantee which function runs first.

When order matters, separate statements are the clearest solution.

int first_value = first();
int second_value = second();

int result =
    first_value + second_value;

This distinction is fundamental:

  • precedence controls structure
  • associativity resolves equal-precedence grouping
  • evaluation order controls execution

They solve different problems.

Tracing a complete expression

The following example combines integer division, a bitmask test, comparison, addition, and assignment.

#include <stdio.h>

#define FLAG_BONUS 0x04U

int main(void) {
    int completed = 7;
    int total = 2;
    unsigned int flags = FLAG_BONUS;

    double score =
        completed / total +
        ((flags & FLAG_BONUS) != 0U);

    printf("%.1f\n", score);
    return 0;
}

A quick mental calculation may suggest:

7 / 2 = 3.5
bonus flag = 1

score = 4.5

The actual output is:

4.0

The first part is integer division.

completed / total

Both operands are int.

7 / 2
→ 3

Next comes the bitwise operation.

flags & FLAG_BONUS

Both values are 0x04U.

0x04U & 0x04U
→ 0x04U

That result is compared with zero.

(flags & FLAG_BONUS) != 0U

The comparison is true, producing the integer 1.

The addition is therefore:

3 + 1
→ 4

Only after that integer result has been produced is it converted to double.

4 → 4.0

To preserve the fractional part, the division must become floating-point before it is evaluated.

double score =
    (double)completed / total +
    ((flags & FLAG_BONUS) != 0U);

Now the calculation is:

7.0 / 2.0
→ 3.5

flag test
→ 1

3.5 + 1.0
→ 4.5

Breaking the expression into smaller operations makes both the value and the type of each intermediate result visible.

What this means for day-to-day C development

Knowing the rules is useful. Writing code that does not force every reader to replay those rules mentally is better.

Choose types based on meaning

Lengths, offsets, error codes, counters, and protocol fields represent different concepts.

Using the same type everywhere may appear convenient, but it can create signedness mismatches or hide invalid states.

The type should fit both the value range and the meaning of the data.

Do not use casts merely to silence warnings

A warning about signedness or narrowing often points to a real mismatch in the data model.

Adding a cast may remove the warning while preserving the bug.

The range and intent should be checked first.

Separate side effects from calculations

This expression is compact but difficult to inspect:

result =
    condition &&
    transform(values[index++]) > limit;

A more explicit version is longer, but the order and side effects are clear.

if (!condition) {
    result = 0;
} else {
    int current = values[index];
    index++;

    int transformed =
        transform(current);

    result =
        transformed > limit;
}

Concise code is useful when it remains obvious. Once type conversion and mutation are mixed together, a few extra lines often make the program safer.

Use parentheses to show intent

if ((flags & MASK) != 0U) {
    /* ... */
}

The parentheses make the bitmask operation visible as one unit. They reduce the reader’s reliance on memorized precedence rules.

Test boundaries, not only ordinary values

Many expression bugs appear at the edges:

  • 0
  • -1
  • minimum and maximum integer values
  • an empty array
  • the largest supported size
  • NULL
  • a shift count of zero
  • a shift count equal to the bit width
  • multiplication just before overflow

Ordinary inputs may never reveal a conversion or overflow problem.

Compiler warnings and sanitizers are part of the workflow

Implicit conversions are easy to miss in source code. Compiler warnings can reveal many of them early.

With GCC or Clang, a useful development configuration might include:

gcc -std=c17 \
    -Wall \
    -Wextra \
    -Wconversion \
    -Wsign-conversion \
    -Wshadow \
    -Wpedantic \
    main.c

These options can help identify:

  • signed and unsigned mismatches
  • narrowing conversions
  • unintended implicit conversions
  • unused expressions or values
  • variables that shadow other variables

Sanitizers can provide additional runtime checks during development.

gcc -std=c17 \
    -Wall \
    -Wextra \
    -fsanitize=undefined,address \
    -fno-omit-frame-pointer \
    main.c

UndefinedBehaviorSanitizer can detect some cases of signed overflow, invalid shifts, and other undefined operations.

AddressSanitizer can detect out-of-bounds memory access and use-after-free errors.

These tools do not replace understanding the language. They are useful because even experienced developers overlook expression details in large codebases.

A few expressions worth checking by hand

Integer division

int left = 7;
int right = 2;

double result = left / right;

printf("%.1f\n", result);

Output:

3.0

The division produces the integer 3 before assignment converts it to double.

Signed and unsigned comparison

int signed_value = -1;
unsigned int unsigned_value = 1U;

printf(
    "%d\n",
    signed_value < unsigned_value
);

Output:

0

The negative value is converted to a large unsigned value before comparison.

Chained comparison

int value = 20;

printf(
    "%d\n",
    0 < value < 10
);

Output:

1

The expression is evaluated as:

(0 < value) < 10

The first comparison produces 1, and 1 < 10 is true.

Bitmask precedence

unsigned int flags = 1U;
unsigned int mask = 2U;

printf(
    "%u\n",
    flags & mask == 0U
);

printf(
    "%u\n",
    (flags & mask) == 0U
);

Output:

0
1

The first expression groups as:

flags & (mask == 0U)

Only the second expression compares the result of the bitwise operation with zero.

Understanding expressions changes how C code is written

When learning C operators, the first goal is usually to remember what each symbol does.

That knowledge is necessary, but it is not what makes expression-heavy code reliable.

The real challenge begins when multiple types and operators appear together.

A double destination does not retroactively turn earlier arithmetic into floating-point arithmetic. Small integer types may be promoted before calculation. A negative value can become a large unsigned value. Logical operators reduce values to truth, while bitwise operators preserve and manipulate their bit patterns. Precedence controls grouping, but not every aspect of execution order.

These are not unrelated language traps. They are consequences of the same design: C evaluates expressions according to both their operators and their types.

Once that becomes familiar, the way code is written begins to change.

Conversions are made where they matter rather than added at the end. Signed and unsigned values are not mixed without thought. Complex expressions are broken apart when their evaluation order is important. Bitmask checks receive explicit parentheses. Allocation sizes are checked before multiplication. Compiler warnings are treated as design feedback rather than noise.

That is the practical value of understanding C expressions.

It is not about memorizing enough rules to solve a tricky output question. It is about recognizing the points where a value can silently change meaning—and writing the code so that neither the compiler nor the next developer has to guess what was intended.

References

저작자표시 비영리 변경금지 (새창열림)