Which platform-specific overflow semantics affect verified data recovery in C?

Answer to the Exact Question

Signed integer overflow is undefined behavior (UB) in the C standard. On platforms that do not use two’s‑complement representation—historical ones’‑complement or sign‑magnitude machines—this UB can lead to divergent bit patterns. When a recovery routine relies on wrap‑around semantics (e.g., an offset that overflows and wraps to zero), the compiler is free to assume the overflow never occurs and can eliminate or transform the corresponding code, especially at optimization levels such as -O2. Consequently, the same artifact may be parsed correctly on a two’s‑complement target (e.g., modern x86‑64) but incorrectly on a non‑two’s‑complement target or when compiled with aggressive optimizations.

Confirmed Facts

• In C, signed overflow is UB; compilers may assume it never happens and perform optimizations that remove runtime checks.
• Two’s‑complement wraparound is formally guaranteed only from C23 onward; earlier standards leave representation unspecified.
• Historical processors (e.g., PDP‑11, early IBM mainframes) used ones’‑complement or sign‑magnitude, producing different overflow results.
• Compilers such as GCC and Clang, when invoked with -O2 or higher, will fold signed arithmetic that overflows into dead code or other expressions.
• Using unsigned types or checked arithmetic (e.g., __builtin_add_overflow) eliminates the UB and makes the behavior deterministic across conforming implementations.

Practical Steps for Reliable Recovery

1. Choose the right type. Use size_t or fixed‑width unsigned types (uint32_t, uint64_t) for all offsets, lengths, and checksum accumulators.
2. Guard arithmetic. Where signed math is unavoidable, employ compiler intrinsics that detect overflow (e.g., __builtin_add_overflow) or use a library providing checked operations.
3. Disable aggressive optimizations for critical paths. Compile the recovery module with -O1 -fno-strict-overflow or add __attribute__((noinline)) to functions that perform parsing.
4. Validate representation. At startup, assert that sizeof(int)==4 and that INT_MAX==0x7FFFFFFF to confirm two’s‑complement; otherwise, fall back to a portable implementation.
5. Static analysis. Run clang-tidy with the -checks=overflow flag or cppcheck --enable=all to flag potential UB before shipping.
6. Cross‑platform testing. Build the recovery binary on at least two distinct architectures (e.g., x86‑64 and an emulator of a ones’‑complement machine) and compare checksum results on a known‑good archive.

Verification Command Example

# minimal UB test – compile with -O2
cat > overflow.c <<'EOF'
#include <stdio.h>
int main(){
    int a = 0x7FFFFFFF; // INT_MAX on 32‑bit
    int b = a + 1;       // signed overflow
    printf("%d\n", b);
    return 0;
}
EOF

cc -O2 overflow.c -o overflow
objdump -d overflow | grep -A5 "add"   # inspect if overflow guard removed

Missing Diagnostic Detail

To tailor the recommendation precisely, could you confirm whether the target platform guarantees two’s‑complement representation (e.g., INT_MAX == 0x7FFFFFFF) or uses an older representation? This detail determines whether the default signed‑overflow assumptions are safe or whether you must enforce unsigned arithmetic everywhere.