Test iOS integer overflow in capacity calculations on a cloud Mac

A download module reserves capacity as “number of chunks × chunk size,” while image processing allocates a buffer as “number of rows × bytes per row.” These calculations usually work without incident. With a corrupted file or unexpected API data, however, they can trigger integer overflow and crash the application. On a cloud Mac, you can extract the arithmetic into a standalone Swift executable and build reliable boundary regression checks for an iOS project without launching a simulator.

Define a contract for capacity calculations first

This article deals only with nonnegative integer capacities, not floating-point approximations. The contract has three rules: negative values are invalid input; results outside the Int range produce an overflow error; and the divisor for ceiling division must be greater than zero. Zero capacity is valid, but a zero divisor is not.

Do not convert inputs to an unsigned type before validating them. A normal conversion from a negative value to an unsigned integer can trap immediately, while a truncating conversion can turn it into a huge positive value. For string inputs, first verify that parsing as Int succeeded. Do not treat a parsing failure as zero.

A representable arithmetic result does not mean the corresponding capacity can be allocated. Integer range checks and application quota checks are independent gates. Both must pass before resources can be allocated.

Give “item count,” “bytes per item,” and “total bytes” distinct names to avoid mixing units. Errors should also identify the stage of the calculation, but logs should not include raw sensitive input in full.

Use overflow-reporting arithmetic instead of wrapping

The standard + and * operators trigger a runtime error on overflow. The &+ and &* operators explicitly wrap instead, potentially turning an excessive capacity into a small value. Capacity validation calls for overflow-reporting arithmetic: obtain both the result and an overflow flag, check the flag first, and only then use the result.

Save the following code as arithmetic.swift. It has no dependency on the application project and does not perform any actual large memory allocations.

enum CapacityError: Error, Equatable {
    case invalidInput
    case overflow
}

func checkedAdd(_ a: Int, _ b: Int) throws -> Int {
    guard a >= 0, b >= 0 else {
        throw CapacityError.invalidInput
    }
    let result = a.addingReportingOverflow(b)
    guard !result.overflow else {
        throw CapacityError.overflow
    }
    return result.partialValue
}

func checkedMultiply(_ a: Int, _ b: Int) throws -> Int {
    guard a >= 0, b >= 0 else {
        throw CapacityError.invalidInput
    }
    let result = a.multipliedReportingOverflow(by: b)
    guard !result.overflow else {
        throw CapacityError.overflow
    }
    return result.partialValue
}

func ceilingDivide(_ n: Int, by d: Int) throws -> Int {
    guard n >= 0, d > 0 else {
        throw CapacityError.invalidInput
    }
    let q = n / d
    return n % d == 0 ? q : try checkedAdd(q, 1)
}

func require(_ condition: Bool) {
    guard condition else {
        fatalError("Boundary check failed")
    }
}

func expectError(
    _ expected: CapacityError,
    _ operation: () throws -> Int
) {
    do {
        _ = try operation()
        fatalError("Expected capacity error")
    } catch let error as CapacityError {
        require(error == expected)
    } catch {
        fatalError("Unexpected error type")
    }
}

require(try checkedAdd(Int.max, 0) == Int.max)
require(try checkedMultiply(Int.max, 1) == Int.max)
require(try checkedMultiply(0, Int.max) == 0)
require(try ceilingDivide(0, by: 4) == 0)
require(try ceilingDivide(8, by: 4) == 2)
require(try ceilingDivide(9, by: 4) == 3)
require(try ceilingDivide(Int.max, by: 1) == Int.max)
require(try ceilingDivide(Int.max, by: 2) == Int.max / 2 + 1)

expectError(.overflow) {
    try checkedAdd(Int.max, 1)
}
expectError(.overflow) {
    try checkedMultiply(Int.max, 2)
}
expectError(.invalidInput) {
    try checkedMultiply(-1, 0)
}
expectError(.invalidInput) {
    try ceilingDivide(1, by: 0)
}
expectError(.invalidInput) {
    try ceilingDivide(Int.min, by: -1)
}

Multiplying a negative value by zero deliberately tests the validation order. If the implementation takes a shortcut and returns zero whenever a factor is zero, invalid input can bypass the contract. Tests must check the error type, not merely confirm that some error occurred.

Do not add the divisor first when rounding up

The number of chunks is often calculated as (n + d - 1) / d. Mathematical correctness does not guarantee safety with fixed-width integers: the addition can overflow even when the final quotient is small.

The example calculates the quotient and remainder first, then adds one only if there is a remainder. Restricting inputs to nonnegative dividends and positive divisors also avoids the special signed-integer overflow case of dividing the minimum value by negative one.

Tests should cover at least zero, exact division, a remainder of one, the maximum integer, and a zero divisor. Do not replace Int.max with a hard-coded decimal constant. Using the type’s own boundary tests the integer width of the actual compilation target, rather than a platform assumption recalled by the developer.

Run in both build modes

The cloud Mac needs a selected development toolchain. First confirm that the compiler is available, then compile and run in each mode:

set -eu
xcrun swiftc --version
mkdir -p .arithmetic-check
xcrun swiftc -Onone arithmetic.swift \
  -o .arithmetic-check/debug
.arithmetic-check/debug
xcrun swiftc -O arithmetic.swift \
  -o .arithmetic-check/optimized
.arithmetic-check/optimized

On success, the program exits silently. Any failed check or unhandled error causes the step to fail. Do not pipe the output in a way that replaces the program’s exit status with a logging tool’s success status.

The example does not use assert, because optimized builds may remove it. The custom require function uses an explicit condition and fatalError, preserving the checks in both modes used here. Do not enable additional nonstandard optimization settings that weaken runtime safety checks.

Check resource limits when integrating with the application

This standalone program provides a minimal verification of the arithmetic contract. For production integration, the application and tests should reference the same production implementation, rather than maintaining two similar sets of functions over time.

Check the call chain in this order:

• Return an error immediately if parsing the raw input fails. Do not continue with a default capacity.
• Make sure all units are consistent before performing checked multiplication and addition, so intermediate expressions cannot overflow first.
• Compare the result against the product-defined quota for a single operation before deciding whether to allocate resources.
• Use a failable exact conversion when converting to a narrower integer type, and reject truncation.
• Verify that failure paths do not create files, allocate buffers, or submit subsequent tasks.

Finally, add a case that is arithmetically valid but exceeds the application quota, and confirm that it is handled separately from overflow errors. When investigating failures, you can then distinguish invalid input, values that do not fit the integer type, and rejection by resource policy, rather than treating every boundary issue as an out-of-memory condition.

Frequently asked questions