C Operators — How Integer Division Cost a Bank

Every useful program on the planet — from a banking app calculating your balance to a game engine deciding if a bullet hit a target — makes decisions and performs calculations. None of that is possible without operators. They are the verbs of your code. If variables are the nouns, operators are the actions performed on those things. Understanding them deeply is not optional — it's the foundation everything else is built on.

Before operators existed in programming languages, writing even simple math required multiple low-level machine instructions. C gave programmers a concise, expressive set of symbols that map closely to what the hardware actually does — which is why C is still used in embedded systems, operating systems, and performance-critical software today. Operators solve the problem of expressing computation, comparison, and logic in a way that is both human-readable and highly efficient.

By the end of this article you'll know every major category of C operator, understand exactly what each one does and why it exists, be able to read real C code without getting tripped up by symbols like >>= or !=, know the silent rules around integer division, negative modulus, and undefined behaviour with increment operators, and you'll know the most common operator mistakes beginners make — so you can avoid them from day one.

Why Integer Division Is Not Your Friend

C operators are symbols that tell the compiler to perform specific mathematical, relational, or logical manipulations on data. At their core, they map directly to CPU instructions — no abstraction layer, no safety net. The critical distinction from higher-level languages is that C operators operate on raw memory values with fixed bit widths, and integer division truncates toward zero, discarding the fractional part entirely.

When you write a / b in C with both operands as integers, the result is an integer. There is no implicit promotion to floating-point. This means 5 / 2 yields 2, not 2.5. The remainder is computed separately with the % operator. This behavior is defined by the C standard (C99 onward) as truncation toward zero — positive results round down, negative results round up. The same rule applies to the modulo operator: -5 % 2 gives -1, not 1.

Use integer division when you explicitly need whole-number results — counting items, indexing arrays, or computing discrete quantities. Never use it for financial calculations, percentages, or any operation where fractional precision matters. The infamous 1994 Pentium FDIV bug aside, integer division in C has silently cost banks millions: a currency conversion that truncated cents instead of rounding them, applied across millions of transactions, produces a systematic loss that only shows up in audit.

Arithmetic Operators — Your Program's Built-In Calculator

Arithmetic operators do exactly what the name suggests: math. C gives you six of them — addition (+), subtraction (-), multiplication (*), division (/), modulus (%), and unary negation (-). You already know the first four from school. The ones that surprise beginners are modulus and integer division.

Modulus (%) gives you the remainder after integer division. So 10 % 3 gives you 1, because 10 divided by 3 is 3 with 1 left over. This is useful in real code for checking if a number is even or odd, wrapping a value around a range (keeping a game character on screen, cycling through a circular buffer), or extracting digits from a number. However, there is a rule that catches people: in C99 and later, the sign of the modulus result follows the sign of the dividend, not the divisor. So -7 % 3 gives -1, not 2. If you need a guaranteed non-negative remainder, use the safe idiom: ((n % m) + m) % m.

The bigger trap is integer division. When you divide two integers in C, you get integer division — the decimal part is thrown away, not rounded, just discarded silently. 7 / 2 gives 3. There is no warning, no error, no indication that anything was lost. If you need the decimal result, at least one of the operands must be a float or double before the division happens — casting after the fact is too late, the truncation has already occurred.

Here's a real-world example from a payment system: the code computed int cents_per_user = total_cents / user_count;. Because both operands were int, the ten-thousandths of a cent were silently dropped on every transaction. After 50,000 transactions, the cumulative error exceeded $10. The fix was a single cast to double. Always cast before division, not after.

#include <stdio.h>

// io.thecodeforge — arithmetic operators demonstration

int main() {
    int apples = 17;
    int children = 5;

    // Basic arithmetic
    int total_after_buying_more = apples + 8;   // addition
    int eaten                   = apples - 3;   // subtraction
    int doubled                 = apples * 2;   // multiplication

    // Integer division: the decimal part is SILENTLY dropped, never rounded
    int each_child_gets = apples / children;    // 17 / 5 = 3 (not 3.4)

    // Modulus: gives the leftover after integer division
    int leftover_apples = apples % children;    // 17 % 5 = 2

    printf("Apples after buying more : %d\n", total_after_buying_more);
    printf("Apples after eating 3    : %d\n", eaten);
    printf("Apples if doubled        : %d\n", doubled);
    printf("Each child gets          : %d apples (decimal lost!)\n", each_child_gets);
    printf("Leftover apples          : %d\n", leftover_apples);

    // To preserve the decimal, cast BEFORE division — not after
    double precise_share = (double)apples / children;
    printf("Precise share per child  : %.2f apples\n", precise_share);

    // Even/odd check with modulus
    int mystery_number = 42;
    printf("%d is %s\n", mystery_number,
           (mystery_number % 2 == 0) ? "even" : "odd");

    // Negative modulus — sign follows the DIVIDEND in C99/C11
    int neg_result = -7 % 3;   // gives -1, not 2
    printf("-7 %% 3 = %d  (sign follows dividend in C99)\n", neg_result);

    // Safe non-negative remainder for wrapping (e.g. circular buffer index)
    int m = 3;
    int safe = ((-7 % m) + m) % m;
    printf("Safe non-negative remainder of -7 mod 3 = %d\n", safe);

    return 0;
}

C Operators Quick Reference Tables

Below are compact tables for every major operator category in C. Each table lists the operator symbol, its name or description, a short explanation, and a simple code example. Use these as a quick lookup when you need to recall the syntax or behaviour of a particular operator.

---

Arithmetic Operators

---

Relational Operators

---

Logical Operators

---

Bitwise Operators

---

Assignment Operators

---

Increment and Decrement Operators

---

Other Operators

Operator Precedence and Associativity — The Complete Table

Operator precedence determines the order in which operators are evaluated in an expression without parentheses. Associativity determines the order when operators of the same precedence appear together (left‑to‑right or right‑to‑left). C has 15 precedence levels. When in doubt, use parentheses — they never cost runtime performance and always make the intent explicit.

Below is the complete precedence table, with level 1 being the highest precedence (evaluated first) and level 15 the lowest.

Always parenthesize when mixing bitwise and logical operators with relational ones: if ((x & MASK) == 0) — without the parentheses, & binds tighter than ==, so x & MASK == 0 is parsed as x & (MASK == 0), which is almost certainly wrong.

Another common pitfall: if (a = b & c) is parsed as a = (b & c) because assignment is level 14 and bitwise AND is level 8. That may be what you want, but the intent is unclear. Use parentheses to show intent.

#include <stdio.h>

int main() {
    int a = 5, b = 3, c = 2;
    int result;

    // Example 1: arithmetic beats relational
    // 5 + 3 > 2 * 2  ->  8 > 4  ->  1
    result = a + b > b * c;
    printf("%d + %d > %d * %d = %d  (correct)\n", a, b, b, c, result);

    // Example 2: assignment is low, so this works
    int x;
    x = a + b * c;   // = 5 + 6 = 11
    printf("x = %d\n", x);

    // Example 3: parentheses fix ambiguity
    // Without parens: a & b == c -> a & (b == c) -> 5 & (3==2) -> 5 & 0 -> 0
    int wrong = a & b == c;
    int right = (a & b) == c;
    printf("Without parens: %d & %d == %d = %d (wrong!)\n", a, b, c, wrong);
    printf("With parens   : (%d & %d) == %d = %d (correct)\n", a, b, c, right);

    return 0;
}

Relational and Logical Operators — Teaching Your Program to Make Decisions

Arithmetic operators crunch numbers. Relational operators compare them and return either 1 (true) or 0 (false). They are the basis of every if-statement, every loop condition, every decision your program makes. C has six: == (equal to), != (not equal to), > (greater than), < (less than), >= (greater than or equal to), and <= (less than or equal to).

Logical operators let you combine those comparisons. Think of them as the words 'and', 'or', and 'not' in English. In C: && means AND (both conditions must be true), || means OR (at least one must be true), and ! means NOT (flips true to false or false to true).

Here is a real-world framing: you are building access control for a theme park ride. The rule is: the rider must be at least 120 cm tall AND no taller than 200 cm AND either be 18 or over OR have a parent present. That is three conditions, two operators, and the kind of compound logic that appears in virtually every non-trivial program ever written.

Short-circuit evaluation is the behaviour you must understand: with &&, if the left side is false, C skips the right side entirely — it cannot change the result. With ||, if the left side is true, the right side is skipped. This matters enormously when the right side has side effects (function calls, pointer dereferences, increments). The idiom if (ptr != NULL && *ptr == 'A') is safe precisely because of short-circuit evaluation — the dereference only happens when the pointer is non-null. Flip the order and you have a crash waiting to happen.

Another real example: a logging module had if (log_level >= DEBUG && printf("%s", msg)) — the developer intended to log only if level was high enough, but the printf always executed because it was on the right of && and the left was true. Short-circuit saved the printf from running when the left was false, but when left was true, the printf ran and its return value (number of chars printed) was truthy. That's not a bug per se, but it shows how side-effects in conditions can lead to confusion.

#include <stdio.h>

// io.thecodeforge — relational and logical operators demonstration

int main() {
    int height_cm          = 145;
    int age                = 12;
    int has_parent_with_them = 1;  // 1 = true, 0 = false in C

    // --- Relational Operators: each returns 1 or 0 ---
    printf("height_cm > 120 : %d\n", height_cm > 120);  // 1
    printf("height_cm > 200 : %d\n", height_cm > 200);  // 0
    printf("height_cm != 200: %d\n", height_cm != 200); // 1
    printf("height_cm == 145: %d\n", height_cm == 145); // 1

    // --- Logical AND (&&): both sides must be true ---
    // Short-circuits: if left is false, right is never evaluated
    int allowed_on_ride = (height_cm >= 120) && (height_cm <= 200);
    printf("\nAllowed on ride (height in range): %d\n", allowed_on_ride);

    // --- Logical OR (||): at least one side must be true ---
    // Short-circuits: if left is true, right is never evaluated
    int can_enter_park = (age >= 18) || (has_parent_with_them == 1);
    printf("Can enter park (adult OR has parent): %d\n", can_enter_park);

    // --- Logical NOT (!): flips true to false and vice versa ---
    int is_minor = !(age >= 18);
    printf("Is a minor: %d\n", is_minor);

    // --- Short-circuit safety: pointer check before dereference ---
    // The dereference only happens when ptr is non-NULL.
    // This is safe and idiomatic C — rely on short-circuit here.
    const char *ptr = "Hello";
    if (ptr != NULL && *ptr == 'H') {
        printf("First character is H\n");
    }

    // --- Combined condition ---
    if (allowed_on_ride && can_enter_park) {
        printf("\nWelcome! Enjoy the ride!\n");
    } else {
        printf("\nSorry, you cannot go on this ride.\n");
    }

    return 0;
}

Assignment and Compound Assignment Operators — Writing Less, Doing More

The single equals sign (=) in C is the assignment operator. It takes the value on the right and stores it in the variable on the left. It does not check equality — that is ==. A useful mental habit: read = as 'gets the value of', not 'equals'. It prevents the = versus == confusion at the thinking stage, before your fingers reach the keyboard.

C also gives you compound assignment operators, which combine an arithmetic operation with assignment into one step. Instead of writing score = score + 10, you write score += 10. They are shorthand — nothing more. But they appear everywhere in real C code and reading them fluently matters.

The full set is: += (add and assign), -= (subtract and assign), *= (multiply and assign), /= (divide and assign), and %= (modulo and assign). There are also bitwise compound assignments: &=, |=, ^=, <<=, >>= — you will see these in embedded and systems code for manipulating hardware registers.

Then there is the increment (++) and decrement (--) operator pair. These add or subtract exactly 1. They exist in two forms: prefix (++counter) and postfix (counter++). The difference only matters when the result is used inside a larger expression. Prefix increments first and returns the new value. Postfix returns the current value and then increments. In a simple for loop where the result is discarded, the two are identical. When used inside a larger expression, the difference is concrete — and modifying the same variable twice in the same expression crosses into undefined behaviour territory, which means the compiler can do whatever it likes and still be technically correct.

A classic interview question: int i = 0; int a = i++ + ++i; What is a? The answer: undefined behaviour. You're modifying i twice between sequence points. The compiler may produce 0, 2, or anything else.

#include <stdio.h>

// io.thecodeforge — assignment and increment operators demonstration

int main() {
    int player_score = 100;

    // Compound assignment: read as 'score gets score plus 50'
    player_score += 50;    // equivalent to: player_score = player_score + 50
    player_score *= 2;     // equivalent to: player_score = player_score * 2
    printf("Score after += 50 then *= 2: %d\n", player_score); // 300

    // --- Prefix vs Postfix: ONLY matters when the result is used ---
    int counter = 5;

    // Postfix: 'a gets the current value, THEN counter increments'
    int a = counter++;   // a = 5, counter becomes 6
    printf("After postfix (counter++): a=%d, counter=%d\n", a, counter);

    // Prefix: 'counter increments FIRST, THEN b gets the new value'
    int b = ++counter;   // counter becomes 7, b = 7
    printf("After prefix  (++counter): b=%d, counter=%d\n", b, counter);

    // In a for loop, prefix and postfix are IDENTICAL — result is discarded
    printf("For loop (postfix and prefix behave the same here):\n");
    for (int i = 0; i < 3; i++) {
        printf("  i = %d\n", i);
    }

    // --- DANGER: modifying a variable twice in one expression ---
    // arr[i++] + arr[i++] is UNDEFINED BEHAVIOUR in C.
    // The compiler is free to evaluate operands in any order.
    // Do NOT do this. Separate onto individual lines:
    int arr[] = {10, 20, 30, 40};
    int idx = 0;
    int val = arr[idx];  // use current index
    idx++;               // then increment — unambiguous, always correct
    printf("Safe indexed access: arr[0] = %d, next index = %d\n", val, idx);

    return 0;
}

Prefix vs Postfix Increment and Decrement — Side-by-Side Comparison

The increment (++) and decrement (--) operators each come in two forms: prefix (before the variable) and postfix (after the variable). Understanding the difference is critical because they behave identically in simple statements but diverge when used inside larger expressions. This side-by-side comparison gives you a clear mental model.

When the result is used (assigned, passed, etc.): - Prefix: changes the variable first, then returns the new value. - Postfix: returns the old value first, then changes the variable.

When the result is discarded (standalone statement): - Both prefix and postfix produce the same final value in the variable. The difference is irrelevant.

When the variable is modified more than once between sequence points: - Both are undefined behaviour — the compiler may do anything. Always avoid.

A quick rule of thumb: if you are just incrementing a loop counter and don't need the old value, use prefix (++i) to avoid any temptation to write i++ inside a larger expression. In practice, any good compiler will generate identical machine code for both in a standalone statement, so focus on clarity. The real danger is expressions like arr[i++] = arr[i] + 1 — that modifies i once in a compound assignment and also reads i on the right, which is undefined behaviour because there is no sequence point between the read on the right and the modification on the left. Always write such code as separate statements.

Also note: the comma operator does NOT introduce a sequence point between its left and right operands; it only guarantees left-to-right evaluation with a sequence point at the comma. So i++, j = i is well-defined because the comma operator has a sequence point. But i++ + i++ does not have a sequence point between the two evaluations of i, hence undefined.

#include <stdio.h>

int main() {
    int x, y;

    // Side-by-side comparison
    x = 5;
    y = ++x;   // prefix: x becomes 6, y gets 6
    printf("Prefix:  x=%d, y=%d\n", x, y);

    x = 5;
    y = x++;   // postfix: y gets 5, x becomes 6
    printf("Postfix: x=%d, y=%d\n", x, y);

    // Array indexing example
    int arr1[] = {10, 20, 30};
    int arr2[] = {10, 20, 30};
    int i = 0;

    // Postfix: use current i as index, then increment
    printf("\narr1[i++] = %d, i after = %d\n", arr1[i++], i); // 10, 1

    i = 0; // reset
    // Prefix: increment first, then use new i as index
    printf("arr2[++i] = %d, i after = %d\n", arr2[++i], i); // 20, 1

    return 0;
}

Bitwise Operators — Working Directly With the Zeros and Ones

Every value in your computer is stored as binary — a sequence of 0s and 1s called bits. Bitwise operators let you manipulate those individual bits directly. This sounds advanced, but it is used everywhere: setting hardware flags in embedded systems, optimising memory in tight loops, building permission systems (the read/write/execute flags in Linux file permissions are a textbook example), and implementing fast operations in graphics and networking code.

C has six bitwise operators: & (AND), | (OR), ^ (XOR), ~ (NOT/complement), << (left shift), and >> (right shift).

AND (&) returns 1 for each bit position where both operands have a 1. It is the masking operator — use it to check whether a specific bit is set. OR (|) returns 1 where either operand has a 1 — use it to set a bit. XOR (^) returns 1 where the bits differ and 0 where they match — which is why XORing a value with 1 always flips that bit. This makes XOR the toggle operator: apply it twice to the same value with the same mask and you get back exactly where you started.

NOT (~) inverts every bit. Left shift (<<) shifts all bits toward higher significance — shifting left by 1 is equivalent to multiplying by 2, shifting left by n is multiplying by 2^n. Right shift (>>) moves bits toward lower significance — for unsigned integers this divides by 2^n. For signed negative integers, right shift behaviour is implementation-defined: some platforms fill the vacated bits with the sign bit (arithmetic shift), others fill with zeros (logical shift). This is why the rule exists: always use unsigned int or a fixed-width type from stdint.h for bitwise operations.

A practical example from a network protocol: parsing a 4-byte header where bits 0-3 contain the version, bits 4-7 contain the header length, and bits 8-31 contain the payload length. You'd mask and shift like: version = header & 0x0F; header_len = (header >> 4) & 0x0F; payload_len = (header >> 8) & 0xFFFFFF;. Without unsigned types, shifting a signed integer right could propagate the sign bit and corrupt the values.

#include <stdio.h>
#include <stdint.h>

// io.thecodeforge — bitwise operators: flags, masking, toggling, shifting

int main() {
    // Permission flags — each is a single bit in a bitmask
    // Using 1u (unsigned literal) to avoid signed-type warnings
    uint8_t READ    = 1u << 2;  // 0000 0100  (decimal 4)
    uint8_t WRITE   = 1u << 1;  // 0000 0010  (decimal 2)
    uint8_t EXECUTE = 1u << 0;  // 0000 0001  (decimal 1)

    // Set READ and WRITE using OR (|)
    uint8_t user_perms = READ | WRITE;  // 0000 0110  (decimal 6)
    printf("Initial permissions : %u (binary: READ|WRITE)\n", user_perms);

    // Check if a bit is set using AND (&)
    // If the bit is present, (perms & FLAG) is non-zero (truthy)
    if (user_perms & READ) {
        printf("Access granted      : Read enabled\n");
    }
    if (!(user_perms & EXECUTE)) {
        printf("Access denied       : Execute not set\n");
    }

    // Toggle a bit using XOR (^)
    // XOR with 1 flips the bit; apply twice to restore original value
    user_perms ^= WRITE;   // clears WRITE bit
    printf("After toggle WRITE  : %u (WRITE cleared)\n", user_perms);
    user_perms ^= WRITE;   // sets WRITE bit again
    printf("After toggle again  : %u (WRITE restored)\n", user_perms);

    // Clear a bit using AND with NOT (~)
    user_perms &= ~WRITE;  // forces the WRITE bit to 0
    printf("After clear WRITE   : %u\n", user_perms);

    // Left shift: multiply by powers of 2 (fast, single CPU instruction)
    unsigned int x = 3;
    printf("\n3 << 1 = %u  (3 * 2 = 6)\n",  x << 1);
    printf("3 << 2 = %u  (3 * 4 = 12)\n", x << 2);

    // Right shift: divide by powers of 2 (safe only on unsigned)
    unsigned int y = 16;
    printf("16 >> 1 = %u  (16 / 2 = 8)\n",  y >> 1);
    printf("16 >> 2 = %u  (16 / 4 = 4)\n",  y >> 2);

    // XOR swap — classic interview trick
    // Works because a ^ a = 0 and a ^ 0 = a
    // The if guard is required: XORing a value with itself gives 0
    unsigned int p = 7, q = 13;
    printf("\nBefore XOR swap: p=%u, q=%u\n", p, q);
    if (&p != &q) { p ^= q; q ^= p; p ^= q; }
    printf("After  XOR swap: p=%u, q=%u\n", p, q);

    return 0;
}

Ternary Operator and Comma Operator — Compact but Dangerous

C offers two lesser-known operators that can make code either elegantly compact or genuinely hard to read. Knowing both is important — you will encounter them in production codebases and interviews, and misreading either one leads to real bugs.

The ternary operator (?:) is a shorthand if-else that returns a value. Syntax: condition ? value_if_true : value_if_false. It returns a value, so you can use it inside assignments, function arguments, or anywhere an expression is expected. It is best used for simple, clear conditional assignments. Chaining ternaries — condition_a ? a : condition_b ? b : c — is technically legal but a code smell that harms readability without saving meaningful lines. If you find yourself nesting them, use an if-else chain instead.

The comma operator (,) evaluates its left operand, discards the result, then evaluates its right operand and returns that. It has the lowest precedence of any C operator, which means assignment binds tighter: y = 1, 2, 3 is parsed as (y = 1), 2, 3 — y gets 1, and 2 and 3 are evaluated and discarded. The comma is most legitimately used in for-loop headers to initialise or update multiple variables in lockstep. Its use elsewhere is mostly a maintenance hazard — it appears in macros and obfuscated code, and the precedence surprise catches people who are not expecting it.

Another use: if (err && (printf("error: %s ", err), 0)) — this prints the error and then evaluates to 0, so the if body is skipped. But it's ugly. Most style guides forbid comma operator outside of for-loops.

#include <stdio.h>

// io.thecodeforge — ternary and comma operator demonstration

int main() {
    int temperature = 30;

    // Ternary: condition ? value_if_true : value_if_false
    // Returns a value — usable anywhere an expression is valid
    const char *weather = (temperature > 25) ? "Hot" : "Cold";
    printf("Weather: %s\n", weather);

    // Ternary inside printf — concise and readable when simple
    int score = 72;
    printf("Grade: %s\n", (score >= 90) ? "A" :
                           (score >= 75) ? "B" :
                           (score >= 60) ? "C" : "F");
    // Note: the above chaining is borderline — if it grows one more level,
    // switch to if-else. Readability wins over compactness.

    // Comma operator: evaluates left, discards it, returns right
    // Parentheses are required to force comma-operator semantics here
    int x = (1, 2, 3);  // x = 3 (rightmost value)
    printf("x = %d  (comma operator returns rightmost)\n", x);

    // Precedence trap: assignment binds TIGHTER than comma
    // This is: (y = 1), then 2 is evaluated and discarded, then 3 is discarded
    // y ends up as 1, NOT 3
    int y;
    y = 1, 2, 3;  // valid C: (y = 1), 2, 3
    printf("y = %d  (assignment beat comma; y got 1, not 3)\n", y);

    // Comma in for-loop: the legitimate and idiomatic use
    printf("Converging loop (i goes up, j goes down):\n");
    for (int i = 0, j = 4; i <= j; i++, j--) {
        printf("  i=%d, j=%d\n", i, j);
    }

    return 0;
}

sizeof Is a Compiler-Constant, Not a Function — Stop Writing sizeof(int)

Every junior thinks sizeof is a function. It isn't. It's a unary operator evaluated entirely at compile time. No runtime overhead. Zero. The parentheses are only needed when the operand is a type name, not a variable. When you write sizeof buffer instead of sizeof(buffer), you'll still get the same bytes. But when you refactor from an array to a pointer, sizeof(buffer) silently gives you 8 bytes (the pointer) instead of the array's full allocation. That's a real bug I've caught in production code that corrupted heap buffers for months. The fix: always use sizeof on the referenced variable, not the type. And if you must use a type, consider sizeof *pointer first — that trick survives pointer declaration changes. The sizeof operator exists because the hardware needs to know how much stack to allocate or how many bytes to memcpy. It's not magic. It's a constant folded into your binary at compile time.

// io.thecodeforge — c-cpp tutorial

#include <stdio.h>
#include <stddef.h>

void process_buffer(char data[]) {
    // data is a pointer, not an array!
    printf("Array? %zu bytes\n", sizeof(data));  // prints 8 on 64-bit
}

int main() {
    char telemetry[1024];
    printf("Buffer size: %zu bytes\n", sizeof telemetry);  // 1024

    // Common rookie mistake:
    size_t count = sizeof(telemetry) / sizeof(telemetry[0]);  // correct
    // Instead of: sizeof telemetry / sizeof(char);  // fragile
    
    process_buffer(telemetry);  // hidden bug: sizeof returns 8, not 1024
    return 0;
}

Address-of and Dereference — Your Two Lowest-Level Weapons

The & operator gives you the memory address of a variable. The operator fetches the value at that address. That's it. No magic. But the WHY matters more than the HOW. You need & when a function wants to modify your variable directly — that's pass-by-reference in C. You need when you're walking a linked list or reading hardware registers mapped to a memory address. Production rule: use & to hand off ownership to a callee that mutates state. Use * to read what a pointer points to, but always check for NULL first. I've seen segfaults in embedded systems because someone dereferenced a NULL pointer they got from an uninitialized device driver. Always guard dereferences with a null check. And never return a pointer to a stack-local variable — that address is invalid as soon as the function returns. That's why you need malloc or static buffers. The operators themselves are dirt simple. The bugs come from ignoring lifespan and null state.

// io.thecodeforge — c-cpp tutorial

#include <stdio.h>

void set_sensor_offset(int* offset) {
    *offset = 42;  // dereference to write
}

int main() {
    int reading = 0;
    int* ptr = &reading;

    set_sensor_offset(ptr);  // pass address
    printf("Reading: %d\n", reading);  // 42

    // Dereference with null check (production rule)
    if (ptr != NULL) {
        int value = *ptr;
        printf("Dereferenced: %d\n", value);
    }
    return 0;
}

Cast Operators — The Only Thing Worse Than a Cast Is No Cast at All

Casts are explicit type conversions. You're telling the compiler 'I know what I'm doing, shut up and reinterpret these bytes.' That's terrifying and essential. In production code, every implicit conversion is a potential bug. An int to a short truncates silently. A float to an int drops precision without warning. Cast operators make those conversions explicit so your code reviewer can see the risk. WHY you cast: (1) converting between arithmetic types when you need to control truncation, (2) casting void* from malloc to the target pointer (in C++ you must, in C you don't need to but it's harmless), (3) casting between struct pointers in tagged unions or protocol parsing. HOW to cast: type_to_castexpression. That's it. But production rule: prefer explicit casts over implicit conversions. If you see a compiler warning about truncation, put a cast there so everyone knows you meant it. Never cast away const unless you absolutely have to — and even then, consider redesigning. Casts mask bugs. Use them like a scalpel, not a chainsaw.

// io.thecodeforge — c-cpp tutorial

#include <stdio.h>

int main() {
    // Implicit truncation — bug waiting to happen
    int large = 100000;
    short truncated = (short)large;  // explicit: I know this loses data
    printf("Truncated: %d\n", truncated);

    // Float to int with explicit cast
    float sensor_voltage = 3.14159f;
    int integer_part = (int)sensor_voltage;  // drops .14159
    printf("Integer part: %d\n", integer_part);

    // Pointer cast for protocol parsing
    unsigned char raw_buffer[4] = {0x01, 0x02, 0x03, 0x04};
    unsigned int* packet = (unsigned int*)raw_buffer;  // reinterpret bytes
    printf("As int: 0x%08x\n", *packet);  // platform-dependent endianness

    return 0;
}