Module F-5·16 min read

AND/OR/XOR/shift operations, bit flags for permissions and feature toggles, and fast arithmetic tricks.

JJS

Written by Jatin Jain Saraf · Senior Software Engineer

Module F-5 — Bit Manipulation: Flags, Permissions, and Fast Math

Q: Given `permissions = CAN_READ | CAN_WRITE` where `CAN_READ = 1` and `CAN_WRITE = 2`, why does `(permissions & CAN_DELETE) !== 0` correctly evaluate to `false` even though `permissions` is a single combined integer?

`CAN_DELETE` occupies a bit position (`1 << 2` = 4) that was never set to 1 in `permissions`, so AND-ing them together produces 0 at every bit position — the check only reports true when the specific bit being tested is actually set. — Each flag is assigned its own exclusive bit position (`1 << 0`, `1 << 1`, `1 << 2`, ...), so combining flags with `|` never sets bits belonging to flags that weren't included. `permissions` here only has bits 0 and 1 set (READ and WRITE); bit 2 (DELETE) remains 0. AND-ing `permissions` with `CAN_DELETE` isolates just that one bit — since it's 0 in `permissions`, the result is 0, correctly reporting the permission as absent. Option B is false — `&` works identically regardless of how many flags have been combined into the integer; there's no limit tied to flag count. Option C invents an unnecessary reset step; checking a flag never requires modifying `permissions` first. Option D misunderstands bitmasks — a flag doesn't need to have been included in a prior OR expression to be validly checked; checking simply reports whether that bit happens to be set, which correctly returns false here.

Q: Why is `n & (n - 1) === 0` (for `n > 0`) a correct test for "is `n` a power of two"?

A power of two has exactly one bit set (e.g., 8 = `0b1000`); subtracting 1 flips that bit to 0 and every lower bit to 1 (7 = `0b0111`), so the original single set bit and the new bit pattern share no 1-bits in common, making the AND result 0 — a property unique to powers of two. — A power of two in binary always has exactly one bit set, with every other bit 0 (e.g., 16 = `0b10000`). Subtracting 1 from a number whose only set bit is at some position k borrows from that bit, clearing it and setting every bit below it to 1 (16 - 1 = 15 = `0b01111`). Because the original single set bit and the new all-1s-below pattern never overlap, ANDing them always yields 0 — a property that is unique to numbers with exactly one bit set. A non-power-of-two has more than one bit set, so at least one of those bits survives the AND, producing a nonzero result. Option A is false — plenty of non-powers-of-two produce a nonzero result (e.g., 6 & 5 = 4, not 0). Option C is incorrect — many even numbers (like 6 or 12) are not powers of two and correctly fail this test. Option D is a fabricated, incorrect claim about how subtraction relates to binary complement.

Q: According to the module, why is the XOR swap trick (`x ^= y; y ^= x; x ^= y;`) presented as "a curiosity, not a recommendation" for modern TypeScript code?

Destructuring assignment (`[x, y] = [y, x]`) achieves the same swap with equivalent practical performance and substantially better readability, so the XOR version's only remaining value is recognizing it in older code or interview contexts. — The module explicitly states that in modern TypeScript, array destructuring performs the swap with equivalent speed and much clearer intent, and that the XOR trick is worth knowing for recognizing it in older code or interview settings rather than as something to write in new code. Option A is false — the XOR swap works correctly on integers in JavaScript/TypeScript; there's no floating-point issue involved since XOR operates on 32-bit integer representations. Option C inverts the actual comparison — the XOR swap uses zero extra temporary variables, which was traditionally framed as its advantage, not a disadvantage; the module's point is that this advantage no longer matters given how cheap destructuring is. Option D is incorrect — bitwise XOR works correctly on negative numbers via their two's-complement representation; nothing prevents it.

What this module covers: Every number in your program is already a sequence of bits — this module is about working with that sequence directly instead of through the abstraction of arithmetic. It covers the core bitwise operators, how a single integer can store dozens of independent boolean flags, and the handful of bit tricks that show up in permission systems, feature flags, and performance-sensitive code.

Binary, Briefly

Every integer in memory is a sequence of bits — 1s and 0s. The number 13 is 1101 in binary: reading right to left, that's 1 + 0 + 4 + 8 = 13 (each position worth double the one before it, starting at 1). You don't need to convert by hand often, but recognizing that an integer is just a fixed-width row of switches is the entire mental model this module builds on.

typescript

(13).toString(2); // "1101"
parseInt('1101', 2); // 13

The Bitwise Operators

Five operators work directly on the bit representation, comparing or shifting bit-by-bit rather than treating the number as a single value:

typescript

const a = 0b1100; // 12
const b = 0b1010; // 10

a & b;   // 0b1000 = 8  — AND: 1 only where BOTH bits are 1
a | b;   // 0b1110 = 14 — OR: 1 where EITHER bit is 1
a ^ b;   // 0b0110 = 6  — XOR: 1 where the bits DIFFER
~a;      // -13         — NOT: flips every bit (and flips the sign, due to two's complement)
a << 1;  // 0b11000 = 24 — left shift: every bit moves left, multiplying by 2 per shift
a >> 1;  // 0b0110 = 6   — right shift: every bit moves right, dividing by 2 per shift (rounding down)

Analogy: Think of AND, OR, and XOR as three different ways of comparing two rows of light switches, position by position. AND: a light turns on only if both switches at that position are on. OR: on if either is on. XOR: on only if they disagree — one on, one off.

XOR is the one worth sitting with, because its "only when they disagree" property is what makes it useful for toggling: XOR-ing a bit with 1 flips it, and XOR-ing a bit with 0 leaves it unchanged — which is exactly the mechanic bit flags rely on next.

Bit Flags: One Integer, Many Booleans

Instead of storing five separate boolean fields, you can pack up to 32 independent true/false facts into a single integer, one per bit position — commonly called a bitmask.

typescript

const CAN_READ   = 1 << 0; // 0b0001 = 1
const CAN_WRITE  = 1 << 1; // 0b0010 = 2
const CAN_DELETE = 1 << 2; // 0b0100 = 4
const CAN_ADMIN  = 1 << 3; // 0b1000 = 8

// Grant read + write by combining with OR
let permissions = CAN_READ | CAN_WRITE; // 0b0011 = 3

// Check a specific permission with AND
const hasWriteAccess = (permissions & CAN_WRITE) !== 0; // true
const hasAdminAccess = (permissions & CAN_ADMIN) !== 0;  // false

// Add a permission without disturbing the others
permissions |= CAN_DELETE; // now 0b0111 = 7

// Remove a permission without disturbing the others
permissions &= ~CAN_WRITE; // clears just the WRITE bit -> 0b0101 = 5

// Toggle a permission (on becomes off, off becomes on)
permissions ^= CAN_READ; // flips just the READ bit

Each permission gets its own bit position (1 << 0, 1 << 1, 1 << 2...), so combining them with | never overwrites another flag — they occupy entirely separate positions in the same integer. Checking with & isolates just that one bit; every other bit is masked out to zero, so the comparison only ever reflects the flag you asked about.

Why this matters in production: a role/permission system with a handful of booleans stored as five separate boolean columns costs five columns, five reads, and five separate comparisons every time you check "can this user do X." As a single integer, storage is one column, and checking any combination of permissions is a single bitwise comparison — no matter how many flags you add, later, without a schema migration for each one.

Feature Flags as Bits

The same pattern shows up for feature toggles — a single integer field on a user or tenant record can represent "which experimental features are enabled for this account," checked and updated exactly like the permission bits above:

typescript

enum Feature {
  DarkMode = 1 << 0,
  BetaSearch = 1 << 1,
  NewCheckout = 1 << 2,
}

function hasFeature(flags: number, feature: Feature): boolean {
  return (flags & feature) !== 0;
}

let userFlags = Feature.DarkMode | Feature.NewCheckout;
hasFeature(userFlags, Feature.BetaSearch); // false
hasFeature(userFlags, Feature.NewCheckout); // true

This is a lightweight, self-contained pattern for a handful of flags on your own schema. Full feature-flagging platforms (LaunchDarkly, GrowthBook, Statsig) solve a much bigger problem — targeting rules, percentage rollouts, real-time updates without a deploy — but at the storage layer, some of them still boil a user's resolved flag set down to exactly this kind of compact bitmask.

Fast Math with Shifts

Left shift multiplies by 2 per position; right shift divides by 2 per position (discarding the remainder, since bits below the decimal point don't exist in an integer). Because shifting operates directly on the bit pattern rather than going through general-purpose arithmetic, it's a common low-level optimization in code where every cycle counts:

typescript

function fastMultiplyBy8(n: number): number {
  return n << 3; // equivalent to n * 8 (2^3), but computed via shifting
}

function fastDivideBy4(n: number): number {
  return n >> 2; // equivalent to Math.floor(n / 4)
}

function isPowerOfTwo(n: number): boolean {
  return n > 0 && (n & (n - 1)) === 0;
  // A power of two has exactly one bit set (e.g. 8 = 0b1000).
  // Subtracting 1 flips that bit and every bit below it to 1 (7 = 0b0111).
  // AND-ing the two together always produces 0 — for any other number, it won't.
}

isPowerOfTwo is a genuinely useful trick beyond micro-optimization — it shows up any time you're validating buffer sizes, chunk sizes, or hash table capacities (Module F-4), which are conventionally kept as powers of two specifically because it makes the modulo-by-bucket-count step reducible to a fast bitwise AND instead of a division.

Two more small, common ones:

typescript

function countSetBits(n: number): number {
  let count = 0;
  while (n > 0) {
    count += n & 1; // check the lowest bit
    n >>= 1;         // shift everything right by one
  }
  return count;
}

function swapWithoutTemp(pair: [number, number]): [number, number] {
  let [x, y] = pair;
  x ^= y;
  y ^= x;
  x ^= y;
  return [x, y]; // swapped, without a third temporary variable
}

The XOR swap is a genuinely clever trick (three XORs cancel out to swap two values) — but worth naming honestly: in modern TypeScript, [x, y] = [y, x] destructuring is just as fast in practice and vastly more readable. The XOR version is worth knowing because it appears in older codebases and interview settings, not because it's what you should reach for in new code.

Where This Shows Up in Your Stack

Unix file permissions are exactly this pattern at the OS level — chmod 755 is three octal digits, each one a 3-bit mask of read (4) / write (2) / execute (1), combined with the same OR logic used above.
Database permission and role fields: a permissions INTEGER column storing a bitmask avoids a wide, ever-growing table of boolean columns (or a many-to-many join table) for what's fundamentally a fixed, small set of capabilities — common in older or performance-sensitive schemas, though many modern systems now prefer a normalized roles table for readability and extensibility. Knowing both patterns lets you recognize an existing bitmask column instead of mistaking it for an inscrutable magic number.
Hash table capacity (Module F-4): keeping bucket counts as a power of two lets the engine compute hash & (capacity - 1) instead of hash % capacity — a bitwise AND instead of a division, which is measurably cheaper at the scale hash tables operate on.
Binary protocols and encodings: parsing a network packet header, a WebSocket frame, or a compact binary format (protobuf-adjacent, custom TCP framing) routinely involves shifting and masking bytes out of a buffer — this module's operators are the literal toolkit for that, not just an abstraction.

Summary

An integer is a fixed-width row of bits. Bitwise operators work on that representation directly: AND (&), OR (|), XOR (^), NOT (~), left shift (<<), right shift (>>).
Bit flags pack many independent booleans into one integer — one bit position per flag, combined with |, checked with &, cleared with &= ~flag, toggled with ^=.
Shifts implement fast multiply/divide by powers of two, and the n & (n - 1) === 0 trick checks "is this a power of two" in one operation.
The XOR swap is a curiosity, not a recommendation — destructuring assignment is equally fast and far more readable in modern TypeScript.
This shows up at every layer of your stack — Unix permission bits, database permission columns, hash table bucket sizing, and binary protocol parsing all lean on exactly these operators.

The next module returns to the sequential structures this course started with — Stacks: LIFO, the Call Stack, and Expression Parsing — the structure quietly running underneath every function call you've written so far.

Knowledge Check

Given permissions = CAN_READ | CAN_WRITE where CAN_READ = 1 and CAN_WRITE = 2, why does (permissions & CAN_DELETE) !== 0 correctly evaluate to false even though permissions is a single combined integer?

Why is n & (n - 1) === 0 (for n > 0) a correct test for "is n a power of two"?

According to the module, why is the XOR swap trick (x ^= y; y ^= x; x ^= y;) presented as "a curiosity, not a recommendation" for modern TypeScript code?

Test your knowledge with more question sets

Sign in to keep reading

The rest of this module is free — sign in with Google to unlock it and track your progress.

PreviousModule F-4: Hash Maps: Hashing, Collisions, and O(1) Lookups Next Module F-6: Stacks: LIFO, the Call Stack, and Expression Parsing

Discussion

Join the discussion

Loading comments...