Clang vs. Clang
Aggressive compiler optimizations in C and C++ are being blamed for breaking previously working code, especially constant‑time cryptographic routines that must avoid data‑dependent timing. Commenters argue over who bears responsibility when undefined behavior is involved: some say any reliance on UB is simply a bug in the program, while others counter that standards and compiler teams have pushed too much complexity and risk onto developers for modest performance gains. Proposed remedies range from new language features and annotations for constant‑time code, to safer compiler defaults and sanitizers, to writing critical paths in specialized languages or hand‑tuned assembly instead of relying on general‑purpose compilers.
Undefined Behavior and Responsibility
- Large part of the thread debates whether compiler miscompilations under UB are “compiler bugs” or “programmer bugs.”
- One side: if code has UB, it’s fundamentally incorrect; relying on coincidental behavior of a specific compiler version is irresponsible.
- Other side: standards and compilers have expanded UB aggressively to enable marginal optimizations, shifting costs and breakage onto users; for legacy C code this is practically unmanageable.
- Distinction between UB vs “erroneous but defined at compile time” behavior is discussed; many argue more things should be implementation-defined instead of UB.
Constant-Time Crypto & Timing Attacks
- Core complaint: optimizing compilers rewrite constant‑time, branchless crypto routines into branching or data‑dependent code, breaking side‑channel resistance.
- Counterpoint: C’s semantics do not include timing as observable behavior; constant‑time requirements are outside the language model.
- Several note that even assembly doesn’t fully solve timing issues on modern CPUs without special hardware modes; some architectures have DOIT/DOITM-like features, but often only controllable by the OS.
- Consensus: constant‑time crypto in portable C is extremely fragile; some argue it’s effectively impossible.
Suitability of C/C++ and Alternatives
- Many argue C/C++ are simply the wrong tools for constant‑time or high‑assurance security code; suggest new languages or DSLs with explicit timing or safety guarantees.
- Others defend C as still viable with careful discipline, sanitizers, and coding rules, especially outside security‑critical domains.
- Rust is mentioned: safer by default, but still relies on UB in unsafe code and LLVM’s optimizer.
Optimization Benefits vs Costs
- Some posters claim modern optimizations yield modest real‑world speedups (e.g., ~10–20% over decade‑old LLVM) for greatly increased complexity and compile time.
- Others counter that even single‑digit percentage improvements are economically huge at large scale, explaining continued investment in aggressive optimization.
Proposed Solutions and Tooling
- Suggested mechanisms: per‑function attributes/pragma to disable certain optimizations, constant‑time annotations, “boring” or restricted C dialects, or special optimization levels (e.g., “no new branches”).
- Sanitizers (UBSAN, ASAN), static analysis, and CI are widely recommended to detect UB, though people disagree how much UB they actually catch and how hard UB is to avoid in practice.