Bitwise NOT in C — Why ~ Clears Adjacent Permission Bits

Embedded systems, operating system kernels, game engines, network protocols, and cryptography libraries all share one thing in common — they rely heavily on bitwise operators. When a Linux kernel sets a file permission flag, it flips a bit. When a graphics engine packs RGBA color channels into a single 32-bit integer, it uses bit shifts. When a network driver extracts the IP header length from a raw packet, it masks bits. This isn't niche knowledge — it's the lingua franca of systems programming.

The problem bitwise operators solve is deceptively simple: speed and space. Storing 8 boolean flags as 8 separate int variables wastes memory and slows things down. Packing them into a single byte and using bitwise operators to read and write individual flags is both faster and leaner. The CPU handles bitwise operations in a single clock cycle — there's nothing faster in your toolbox.

By the end of this article you'll be able to read and write bit flags confidently, understand exactly how masking and shifting work under the hood, spot the classic bugs that trip up even experienced developers, and answer the bitwise questions that interviewers love to spring on candidates. Let's get into it.

What Bitwise NOT in C Actually Does — And Why It Breaks Permission Bits

Bitwise NOT (~) in C flips every bit in its operand: 0 becomes 1, 1 becomes 0. It operates on the full width of the integer type — for an unsigned char (8 bits), ~0x03 yields 0xFC. This is a unary operator, applied to a single integer expression, and it works on any integer type (char, int, long, etc.). The result is a one's complement of the operand.

Key property: ~ is not a logical negation. It inverts all bits, not just the truthiness of the value. For signed types, the result depends on the underlying two's complement representation — ~0 is -1, not 0. This catches many developers off guard when they expect a simple boolean flip. The operation is O(1) and compiles to a single machine instruction (NOT or XOR with all-ones).

Use ~ when you need to clear specific bits by ANDing with the complement of a mask: flags &= ~PERM_WRITE. This is the canonical pattern for clearing permission bits in systems programming — file access masks, memory page protections, or interrupt enables. Without ~, you'd have to know the exact bit pattern to clear, which is error-prone and unmaintainable.

The Six Bitwise Operators and What They Actually Do

C gives you six bitwise operators: AND (&), OR (|), XOR (^), NOT (~), left shift (<<), and right shift (>>). Each one operates on the individual bits of an integer — not the integer as a whole mathematical value, but the raw binary pattern sitting in memory.

Think of AND as 'both switches must be ON'. OR as 'at least one switch must be ON'. XOR (exclusive OR) as 'exactly one switch must be ON — but not both'. NOT flips every single switch. Left shift moves all switches to the left by N positions, filling vacated positions with zeros — which multiplies by powers of two. Right shift moves everything right, which divides by powers of two.

The key insight beginners miss: these operators don't care about the numeric value you intended. They only see the bit pattern. The number 5 (binary: 00000101) and the number 6 (binary: 00000110) ANDed together produce 4 (binary: 00000100) — not because 5 AND 6 means anything mathematically, but because only the third bit was ON in both patterns.

This distinction between 'value' and 'bit pattern' is everything. Once it clicks, the rest falls into place naturally.

#include <stdio.h>

// Helper: print an integer as 8-bit binary so we can SEE what's happening
void print_binary(const char *label, unsigned int value) {
    printf("%-20s = ", label);
    for (int bit_position = 7; bit_position >= 0; bit_position--) {
        // Shift the bit we care about all the way to position 0, then mask it
        printf("%d", (value >> bit_position) & 1);
    }
    printf(" (decimal: %u)\n", value);
}

int main(void) {
    unsigned int lights_a = 0b00110101; // switches: 6,5 and 4,2 and 0 are ON  = 53
    unsigned int lights_b = 0b00101110; // switches: 5,3,2,1 are ON            = 46

    printf("=== Starting values ===\n");
    print_binary("lights_a",         lights_a);
    print_binary("lights_b",         lights_b);

    printf("\n=== AND — both must be ON ===\n");
    // Only bits that are 1 in BOTH patterns survive
    print_binary("a & b",            lights_a & lights_b);

    printf("\n=== OR — at least one ON ===\n");
    // Any bit that is 1 in EITHER pattern survives
    print_binary("a | b",            lights_a | lights_b);

    printf("\n=== XOR — exactly one ON ===\n");
    // Bits that differ between the two patterns become 1
    print_binary("a ^ b",            lights_a ^ lights_b);

    printf("\n=== NOT — flip everything ===\n");
    // Every 0 becomes 1 and every 1 becomes 0 (we mask to 8 bits for clarity)
    print_binary("~a (8-bit masked)", (~lights_a) & 0xFF);

    printf("\n=== LEFT SHIFT — multiply by 2 per shift ===\n");
    // Shifting left by 2 is the same as multiplying by 4
    print_binary("a << 2",           (lights_a << 2) & 0xFF);

    printf("\n=== RIGHT SHIFT — divide by 2 per shift ===\n");
    // Shifting right by 1 is the same as integer division by 2
    print_binary("a >> 1",           lights_a >> 1);

    return 0;
}

Bit Flags and Masking — The Real-World Pattern You'll Use Every Day

The single most common real-world use of bitwise operators is the bit flag pattern. Instead of storing eight separate boolean variables, you pack them all into one integer — each bit represents one flag. This is how file permissions work in Linux (rwxrwxrwx is nine bits), how TCP/IP headers store control flags (SYN, ACK, FIN), and how game engines store entity states.

Three operations drive the entire pattern:

Setting a bit (turning a flag ON): Use OR with a mask. The mask has a 1 only in the position you want to set. Everything else stays untouched because OR-ing with 0 changes nothing.

Clearing a bit (turning a flag OFF): Use AND with an inverted mask. The inverted mask has a 0 only in the target position, which forces that bit to 0. Everything else stays untouched because AND-ing with 1 changes nothing.

Checking a bit (reading a flag): Use AND with the mask. If the result is non-zero, the bit was set. If zero, it wasn't.

The mask itself is almost always defined using a left shift: 1 << N gives you a mask with exactly one 1 bit at position N. This pattern is so idiomatic in C that you'll see it in virtually every low-level codebase.

#include <stdio.h>

// Define each permission as a bit flag using left shifts
// This makes the intent crystal-clear and avoids magic numbers
#define PERMISSION_READ     (1 << 0)  // bit 0 = 00000001 = 1
#define PERMISSION_WRITE    (1 << 1)  // bit 1 = 00000010 = 2
#define PERMISSION_EXECUTE  (1 << 2)  // bit 2 = 00000100 = 4
#define PERMISSION_DELETE   (1 << 3)  // bit 3 = 00001000 = 8
#define PERMISSION_SHARE    (1 << 4)  // bit 4 = 00010000 = 16

// A single byte can hold all 5 permissions — no wasted memory
typedef unsigned char PermissionSet;

void print_permissions(PermissionSet perms) {
    printf("Permissions: [%s] [%s] [%s] [%s] [%s]\n",
        (perms & PERMISSION_READ)    ? "READ"    : "----",
        (perms & PERMISSION_WRITE)   ? "WRITE"   : "-----",
        (perms & PERMISSION_EXECUTE) ? "EXECUTE" : "-------",
        (perms & PERMISSION_DELETE)  ? "DELETE"  : "------",
        (perms & PERMISSION_SHARE)   ? "SHARE"   : "-----"
    );
}

int main(void) {
    // Start with no permissions at all — a clean slate
    PermissionSet user_permissions = 0;

    printf("--- Initial state ---\n");
    print_permissions(user_permissions);

    // SET bits: grant read and write using OR
    // OR with the flag mask forces that bit to 1 without touching others
    user_permissions |= PERMISSION_READ;
    user_permissions |= PERMISSION_WRITE;
    printf("\n--- After granting READ and WRITE ---\n");
    print_permissions(user_permissions);

    // SET multiple flags at once by OR-ing them together in one line
    user_permissions |= (PERMISSION_EXECUTE | PERMISSION_SHARE);
    printf("\n--- After granting EXECUTE and SHARE ---\n");
    print_permissions(user_permissions);

    // CLEAR a bit: revoke write using AND with the inverted mask
    // ~PERMISSION_WRITE = 11111101 — forces bit 1 to 0, leaves all others
    user_permissions &= ~PERMISSION_WRITE;
    printf("\n--- After revoking WRITE ---\n");
    print_permissions(user_permissions);

    // CHECK a bit: test if the user can execute
    // AND with the flag mask — non-zero means the bit is set
    if (user_permissions & PERMISSION_EXECUTE) {
        printf("\n--- Access check: EXECUTE permission GRANTED ---\n");
    }

    // TOGGLE a bit: flip SHARE using XOR
    // XOR with 1 flips the bit; XOR with 0 leaves it unchanged
    user_permissions ^= PERMISSION_SHARE;
    printf("\n--- After toggling SHARE (was ON, now OFF) ---\n");
    print_permissions(user_permissions);

    return 0;
}

Bit Shifting for Fast Math and Data Packing

Bit shifts are doing two different jobs in real codebases, and conflating them leads to bugs. The first job is fast arithmetic: shifting left by N multiplies by 2^N, shifting right by N divides by 2^N (integer division). Modern compilers do this automatically for power-of-two constants, but you'll still see explicit shifts in performance-critical hot paths and in code that needs to be portable to compilers without optimisation.

The second job is data packing and unpacking — cramming multiple values into a single integer. This is everywhere in real protocols. A 32-bit RGBA color value packs four 8-bit channels. An IPv4 header packs the version number and IHL into a single byte. An audio sample format encodes bit depth, channel count, and sample rate into a single flags integer.

The formula is always the same: shift a value LEFT into its position to pack it, shift RIGHT and mask to unpack it. The mask (typically 0xFF for an 8-bit field, 0xF for a 4-bit field) ensures you only extract the bits that belong to that field and nothing bleeds in from adjacent fields.

This packing technique is also why bitfields in structs exist — they're syntactic sugar over exactly this pattern.

#include <stdio.h>
#include <stdint.h>  // for uint32_t, uint8_t — always use fixed-width types for bit work

// Pack four 8-bit color channels into one 32-bit unsigned integer
// Layout: [ALPHA: bits 31-24] [RED: bits 23-16] [GREEN: bits 15-8] [BLUE: bits 7-0]
uint32_t pack_rgba(uint8_t red, uint8_t green, uint8_t blue, uint8_t alpha) {
    uint32_t packed = 0;
    packed |= ((uint32_t)alpha << 24); // shift alpha into the top 8 bits
    packed |= ((uint32_t)red   << 16); // shift red into bits 23-16
    packed |= ((uint32_t)green <<  8); // shift green into bits 15-8
    packed |= ((uint32_t)blue  <<  0); // blue sits in the lowest 8 bits (no shift needed)
    return packed;
}

// Unpack: shift the target field down to bit-0, then mask off everything above it
uint8_t extract_red(uint32_t packed_color) {
    return (packed_color >> 16) & 0xFF; // shift down 16, keep only lowest 8 bits
}

uint8_t extract_green(uint32_t packed_color) {
    return (packed_color >> 8) & 0xFF;  // shift down 8, keep only lowest 8 bits
}

uint8_t extract_blue(uint32_t packed_color) {
    return packed_color & 0xFF;         // blue is already at bit 0, just mask
}

uint8_t extract_alpha(uint32_t packed_color) {
    return (packed_color >> 24) & 0xFF; // shift down 24, keep only lowest 8 bits
}

// Demonstrate fast multiply/divide with shifts
void demonstrate_shift_arithmetic(void) {
    unsigned int pixel_count = 13;
    printf("\n=== Shift Arithmetic Demo ===\n");
    printf("pixel_count          = %u\n",  pixel_count);
    printf("pixel_count << 1     = %u  (x2 = multiply by 2^1)\n",  pixel_count << 1);
    printf("pixel_count << 3     = %u  (x8 = multiply by 2^3)\n",  pixel_count << 3);
    printf("pixel_count >> 1     = %u  (÷2 = divide by 2^1)\n",   pixel_count >> 1);
}

int main(void) {
    // Pack a coral-ish color: R=255, G=100, B=80, A=200
    uint8_t r = 255, g = 100, b = 80, a = 200;
    uint32_t coral = pack_rgba(r, g, b, a);

    printf("=== RGBA Color Packing Demo ===\n");
    printf("Input  — R:%3u G:%3u B:%3u A:%3u\n", r, g, b, a);
    printf("Packed — 0x%08X (decimal: %u)\n", coral, coral);

    // Now unpack and verify we get the original values back
    printf("\n=== Unpacking Back Out ===\n");
    printf("Extracted — R:%3u G:%3u B:%3u A:%3u\n",
        extract_red(coral),
        extract_green(coral),
        extract_blue(coral),
        extract_alpha(coral)
    );

    demonstrate_shift_arithmetic();

    return 0;
}

XOR Tricks and the Swap Without a Temp Variable

XOR has a remarkable mathematical property: it's its own inverse. If you XOR a value with a key to 'encode' it, XOR-ing the result with the same key gives you the original value back. This property powers simple (though not secure) data obfuscation, checksum algorithms, and one of the most famous C interview tricks: swapping two variables without a temporary.

The XOR swap works because of three applications of the inverse property. After a ^= b, the variable a holds the combination of both values. After b ^= a, b now holds the original a. After a ^= b, a now holds the original b. It reads like magic until you trace the bits.

But here's the honest truth a senior dev will tell you: don't use XOR swap in production. Modern compilers generate a three-instruction register swap that's faster, and the XOR swap silently corrupts both variables if you accidentally call it with the same memory address (i.e., xor_swap(&value, &value) zeroes the variable). It's a brilliant interview answer — and a terrible production choice.

Where XOR legitimately earns its keep is in parity checking, error detection (CRC algorithms use XOR extensively), and finding the unique element in an array where every other element appears twice — a classic algorithm problem that becomes a single-line solution with XOR.

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

// XOR swap — brilliant to understand, don't use in real code
void xor_swap(int *value_a, int *value_b) {
    if (value_a == value_b) return;  // CRITICAL guard — same address would zero both out
    *value_a ^= *value_b;            // a now holds 'a XOR b'
    *value_b ^= *value_a;            // b now holds 'b XOR (a XOR b)' = original a
    *value_a ^= *value_b;            // a now holds '(a XOR b) XOR a' = original b
}

// XOR's inverse property: encode then decode with the same key
void demonstrate_xor_encode(void) {
    uint8_t original_byte  = 0b10110011; // 179 — our data
    uint8_t secret_key     = 0b01101010; // 106 — our key

    uint8_t encoded = original_byte ^ secret_key;  // XOR to obscure
    uint8_t decoded = encoded ^ secret_key;         // XOR again with same key to recover

    printf("=== XOR Encoding Demo ===\n");
    printf("Original : %3u (0x%02X)\n", original_byte, original_byte);
    printf("Key      : %3u (0x%02X)\n", secret_key, secret_key);
    printf("Encoded  : %3u (0x%02X)\n", encoded, encoded);
    printf("Decoded  : %3u (0x%02X) — matches original: %s\n",
        decoded, decoded, (decoded == original_byte) ? "YES" : "NO");
}

// Classic algorithm: find the one number that appears only once
// Every other number in the array appears exactly twice
// XOR-ing a number with itself gives 0; XOR-ing with 0 gives the number itself
int find_unique_element(int *readings, int count) {
    int unique = 0;
    for (int index = 0; index < count; index++) {
        unique ^= readings[index]; // pairs cancel out (N^N=0); the lone value survives
    }
    return unique;
}

int main(void) {
    // Demonstrate XOR swap
    int temperature_celsius = 37;
    int boiling_point       = 100;
    printf("Before swap: temp=%d, boiling=%d\n", temperature_celsius, boiling_point);
    xor_swap(&temperature_celsius, &boiling_point);
    printf("After swap:  temp=%d, boiling=%d\n\n", temperature_celsius, boiling_point);

    demonstrate_xor_encode();

    // Sensor readings — every reading appears twice except one faulty sensor ID
    int sensor_readings[] = {4, 7, 2, 9, 7, 4, 2}; // 9 appears only once
    int reading_count = sizeof(sensor_readings) / sizeof(sensor_readings[0]);
    int faulty_sensor = find_unique_element(sensor_readings, reading_count);
    printf("\n=== Find Unique Sensor ID ===\n");
    printf("Faulty sensor ID: %d (appears only once in the data)\n", faulty_sensor);

    return 0;
}

Bitwise Operator Precedence and Common Gotchas

Bitwise operators have lower precedence than you think. The most dangerous trap is that ==, !=, and relational operators (<, >, <=, >=) all have higher precedence than &, ^, and |.

So if (flags & MASK == 0) is parsed as if (flags & (MASK == 0)), which compares MASK to 0 (always false, resulting in 0), then ANDs flags with 0 — always false. The fix is parentheses: if ((flags & MASK) == 0).

Similarly, if (flags & MASK != 0) is parsed as if (flags & (MASK != 0)). Since MASK is non-zero, MASK != 0 is true (1), so you effectively check flags & 1 — which is rarely what you want.

Production rule: When in doubt, parenthesize every bitwise expression. It costs nothing and prevents bugs that can take hours to find.

#include <stdio.h>

int main(void) {
    unsigned int flags = 0b00001100; // bits 2 and 3 are set
    unsigned int MASK  = 0b00000100; // bit 2

    printf("flags = 0x%X, MASK = 0x%X\n", flags, MASK);

    // WRONG: == has higher precedence than &
    if (flags & MASK == 0) {
        printf("Mistake: (flags & (MASK == 0)) is false, so this prints always\n");
    }

    // CORRECT: explicitly parenthesize
    if ((flags & MASK) != 0) {
        printf("Correct: bit 2 is set\n");
    }

    // Another common trap: mixing bitwise and logical operators without parentheses
    if (flags & MASK && 1) {
        // This is parsed as (flags & MASK) && 1
        // Which works by accident, but don't rely on it
        printf("Works but ambiguous — always parenthesize\n");
    }

    // Shift + AND: make intent clear
    unsigned int extract = (flags >> 2) & 0x0F; // extract bits 2-5
    printf("Extracted bits 2-5: 0x%X\n", extract);

    return 0;
}

Endianness and Bitwise Operators — Why Your Network Packet Just Corrupted

Bitwise operators work on the value, not the memory layout. That sounds obvious until your cross-platform serialisation corrupts every packet. Endianness — the order bytes are stored in memory — does not affect &, |, ^, or ~. They operate on the CPU register where the byte order is already resolved. Shift operators? Same. 0x0102 << 8 is always 0x0200, regardless of whether your machine stores the high byte first or last.

The trap: unions and pointer casts. If you overlay a uint32_t over a uint8_t array to extract bytes, you get different results on x86 (little-endian) vs ARM in big-endian mode. Write code that reads bytes using shifts and masks, not pointer arithmetic. Serialisation libraries like Protocol Buffers handle this for you — but when you roll your own packet parser, test on both endiannesses in CI. Production will find the one you didn't.

Hardware registers are another minefield. Many embedded peripherals document bit fields assuming big-endian storage. Your compiler might pack them differently. Always verify with a union and a known pattern like 0xAA55 before trusting bitfield structs.

// io.thecodeforge — c-cpp tutorial

#include <cstdio>
#include <cstdint>

int main() {
    uint32_t packet_header = 0x12345678;
    
    // Portable byte extraction — works on every endianness
    uint8_t b0 = (packet_header >> 24) & 0xFF;
    uint8_t b1 = (packet_header >> 16) & 0xFF;
    uint8_t b2 = (packet_header >> 8)  & 0xFF;
    uint8_t b3 = packet_header & 0xFF;
    
    printf("Portable: 0x%02X %02X %02X %02X\n", b0, b1, b2, b3);
    
    // Non-portable — union with uint8_t array
    union {
        uint32_t u32;
        uint8_t  bytes[4];
    } hack;
    hack.u32 = packet_header;
    
    printf("Union:    0x%02X %02X %02X %02X\n", 
           hack.bytes[0], hack.bytes[1], 
           hack.bytes[2], hack.bytes[3]);
    return 0;
}

Undefined Behaviour in Shifts — The Compiler Will Gaslight You

Shifting signed integers left into the sign bit is undefined behaviour. Shifting by more than the bit-width of the type? Also undefined. The compiler can assume you never do this — and optimise your error handling into a no-op.

Example: int32_t x = 1 << 31. On your machine, this might set the sign bit to 1. But the C standard says this is UB. A different compiler version might silently remove the line, or trap on ARM. Clang's UB sanitizer will catch it. Your production crash dump won't.

Right shift of negative signed integers is implementation-defined: arithmetic shift (sign-extending) vs logical shift (zero-fill). Most compilers do arithmetic shift, but if you rely on it for a signed-to-unsigned conversion trick, you're writing a time bomb. Always cast to unsigned before shifting if you care about the bit pattern.

Another footgun: << with negative shift count is UB. A junior might write x << (y - offset) where y < offset. That's a hard crash — or worse, silent corruption. Validate your shift counts. Every time.

// io.thecodeforge — c-cpp tutorial

#include <cstdio>
#include <cstdint>
#include <climits>

int main() {
    int8_t  signed_val = -1;
    uint8_t unsigned_val = 0xFF;
    
    // Right shift on signed — implementation-defined
    printf("Signed   >> 4: %d\n", signed_val >> 4);
    printf("Unsigned >> 4: %u\n", unsigned_val >> 4);
    
    // UB: shift too far
    int32_t x = 1;
    // printf("%d\n", x << 33);  // UB. Do not uncomment.
    
    // Safe: mask before shift
    uint32_t status = 0x80000000;
    uint32_t bit_31 = (status >> 31) & 1U;  // Always 1, defined behaviour
    printf("Bit 31: %u\n", bit_31);
    
    return 0;
}

Syntax: How Bitwise Operators Appear in Real Code

Bitwise operators in C look deceptively simple: they're single symbols like &, |, ^, ~, <<, and >>. But their syntax carries side effects that catch even senior engineers. The bitwise AND (&) is not the logical AND (&&); mixing them with conditionals silently breaks control flow. The bitwise OR (|) and XOR (^) follow infix notation, meaning they sit between two integer expressions. The NOT operator (~) is unary and flips every bit — but on signed integers, two's complement makes ~0 equal to -1, not 0xFFFFFFFF unless you cast to unsigned. Shift operators (<<, >>) have a gotcha: the right operand must be less than the width of the left operand's type, or the behavior is undefined. Assignments like &=, |=, ^=, <<=, >>= are compound operators that modify the left operand in place. Always parenthesize bitwise expressions inside conditionals: (flags & MASK) != 0, never (flags & MASK) — that assigns truthiness to the result instead of a boolean. Use unsigned types (uint32_t) for portability; signed shifts are implementation-defined for right shifts of negative values.

// io.thecodeforge — c-cpp tutorial
#include <stdint.h>
#include <stdio.h>

int main() {
    uint8_t flags = 0b10101100; // flags
    uint8_t mask  = 0b00001111; // mask lower nibble

    // Correct syntax: parenthesize bitwise in condition
    if ((flags & mask) != 0) {
        printf("Lower nibble has bits set\n");
    }

    // Compound assignment
    flags |= 0b00000011; // set bits 0-1
    printf("flags = 0x%02X\n", flags);

    // Warning: ~ on signed
    int x = 0;
    unsigned int y = ~0U;
    printf("~0 = %d, ~0U = %u\n", ~x, y);
    return 0;
}

Examples: Bitwise Mastery Through Compilable Snippets

Theory fades fast without concrete examples that compile and produce output. Below are battle-tested patterns for bit twiddling in C. The first example shows how to toggle a permission bit in a Unix-style mode mask — note that ~ on a signed int flips all bits, including the sign, so always cast to unsigned or use a literal suffix. The second example packs two 16-bit values into a 32-bit integer for network packet headers, demonstrating how shifts avoid manual multiplication. The third example performs a XOR swap without a temp variable; it works only for distinct memory locations — swapping with itself zeroes the value. Each snippet uses uint32_t from for guaranteed width. Run them to see the output; the compiler will not warn you about sign extension unless you enable -Wsign-conversion. Always test on your target architecture; endianness affects how packed bytes are interpreted. The XOR trick also finds duplicate items in arrays: XOR all elements with the expected range. These examples represent daily-use patterns in embedded systems and protocol parsing.

// io.thecodeforge — c-cpp tutorial
#include <stdint.h>
#include <stdio.h>

int main() {
    // 1. Toggle permission bit (use unsigned) 
    uint16_t perms = 0b11011010;
    perms ^= 1u << 4;          // toggle bit 4
    printf("perms after toggle: 0x%04X\n", perms);

    // 2. Pack two 16-bit into 32-bit
    uint32_t header = (18u << 16) | 200u;
    printf("packed: 0x%08X\n", header); // 0x001200C8

    // 3. XOR swap (watch aliasing!)
    uint32_t a = 5, b = 3;
    a ^= b; b ^= a; a ^= b;
    printf("swap: %u, %u\n", a, b);

    // 4. Clear lowest set bit (Brian Kernighan)
    uint32_t v = 40; // 101000
    v &= v - 1;
    printf("clear LSB: %u\n", v); // 32 (100000)
    return 0;
}

Endianness: How Bitwise Ops Behave Across Architectures

Endianness refers to the byte ordering of multi-byte data types in memory. Little-endian systems (e.g., x86) store the least significant byte first, while big-endian systems (e.g., some network protocols) store the most significant byte first. Bitwise operators operate on the binary representation of values at the abstract machine level, not on the memory layout. Therefore, the result of bitwise operations is independent of endianness when applied to integer values in registers. However, endianness matters when you interpret the same bytes as different types or when you access individual bytes via pointers or unions. For example, consider a 32-bit integer with value 0x12345678. On a little-endian machine, the memory bytes are 0x78, 0x56, 0x34, 0x12; on big-endian, they are 0x12, 0x34, 0x56, 0x78. If you apply a bitwise NOT to the integer, the result is the same on both architectures: ~0x12345678 = 0xEDCBA987. But if you cast the integer to a char* and read the first byte, you get different values. This is critical when serializing data for network packets or file formats. Always use functions like htonl() and ntohl() to convert between host and network byte order. For bitwise operations on multi-byte fields, endianness does not affect the arithmetic result, but it does affect how you interpret raw memory dumps. In practice, avoid relying on the memory layout of integers; use shift and mask operations to extract bytes portably.

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

int main() {
    uint32_t value = 0x12345678;
    uint32_t not_value = ~value;
    printf("value = 0x%08X\n", value);
    printf("~value = 0x%08X\n", not_value);
    
    // Check first byte via pointer
    unsigned char *bytes = (unsigned char *)&value;
    printf("First byte: 0x%02X (endian-dependent)\n", bytes[0]);
    
    // Portable extraction
    uint32_t first_byte = (value >> 0) & 0xFF;  // always least significant byte
    printf("Portable first byte: 0x%02X\n", first_byte);
    return 0;
}

Bit Fields in Structures: ABI and Portability

Bit fields in C allow you to specify the exact number of bits for a member within a structure. They are useful for packing flags or hardware registers. However, bit fields are highly non-portable due to implementation-defined behavior. The C standard leaves the following aspects unspecified: the allocation order of bit fields within a storage unit (whether they are assigned from most significant bit to least or vice versa), whether a bit field can straddle a storage unit boundary, and the alignment of the storage unit itself. For example, consider a struct with two bit fields: int a:3; int b:5;. On some compilers, a occupies the low-order 3 bits and b the next 5 bits; on others, the order is reversed. This can lead to ABI incompatibilities when libraries compiled with different compilers exchange such structs. Additionally, the signedness of plain int bit fields is implementation-defined (some compilers treat them as signed, others as unsigned). To improve portability, always use unsigned int or explicitly signed/unsigned types. Avoid bit fields for data exchange across compilation units or platforms; use explicit bit masking with shift operators instead. For hardware registers, consult the compiler documentation for the exact layout. In C23, the new header provides standardized bit manipulation functions, but it does not address bit field portability. For production code, prefer manual bit manipulation over bit fields for any external interface.

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

// Non-portable bit field struct
struct Flags {
    unsigned int read : 1;
    unsigned int write : 1;
    unsigned int exec : 1;
    unsigned int reserved : 5;
};

// Portable alternative using explicit masks
#define FLAG_READ  (1U << 0)
#define FLAG_WRITE (1U << 1)
#define FLAG_EXEC  (1U << 2)

int main() {
    struct Flags f = {1, 0, 1};
    printf("Bit field size: %zu bytes\n", sizeof(f));
    
    uint8_t flags = 0;
    flags |= FLAG_READ;
    flags |= FLAG_EXEC;
    printf("Portable flags: 0x%02X\n", flags);
    return 0;
}

Bit Manipulation with in C23

The C23 standard introduced the header, which provides a set of portable functions for common bit manipulation tasks. This includes counting leading zeros (stdc_leading_zeros), counting trailing zeros (stdc_trailing_zeros), counting ones (stdc_popcount), finding the first set bit (stdc_first_leading_one), and many more. These functions are type-generic and work with unsigned integer types up to 64 bits. For example, to count the number of 1 bits in a 32-bit value, you can use stdc_popcount(value). This replaces non-standard compiler builtins like __builtin_popcount or platform-specific intrinsics. The functions are designed to be efficient and may map directly to CPU instructions (e.g., POPCNT on x86). Using improves code portability and readability. However, note that these functions are only available in C23 and later; older compilers may not support them. For production code targeting C23, prefer these standardized functions over manual loops or compiler-specific extensions. The header also includes functions for endian conversion (stdc_byteswap) and bit rotation (stdc_rotl, stdc_rotr). This significantly reduces the need for platform-specific code. When using bitwise NOT in combination with these functions, remember that ~ is still the standard bitwise complement operator. For example, to get the number of zeros in a value, you can compute stdc_popcount(~value). The new standard library functions complement the existing bitwise operators, making bit manipulation safer and more portable.

#include <stdio.h>
#include <stdbit.h>

int main() {
    unsigned int value = 0b10110110;
    printf("popcount(%u) = %u\n", value, stdc_popcount(value));
    printf("leading zeros = %u\n", stdc_leading_zeros(value));
    printf("trailing zeros = %u\n", stdc_trailing_zeros(value));
    printf("first leading one = %u\n", stdc_first_leading_one(value));
    
    // Using bitwise NOT with popcount
    printf("popcount(~value) = %u\n", stdc_popcount(~value));
    return 0;
}