# Fighting Hyrum's Law in LLVM

DevFeed: [Fighting Hyrum's Law in LLVM](<https://devfeed.tech/articles/fighting-hyrum-s-law-in-llvm-31128.md>)

Original publisher: [Read original article](<https://maskray.me/blog/fighting-hyrums-law-in-llvm>)

Published: 2026-05-10T07:00:00Z

Content type: article

Language: en

Sources: [MaskRay](<https://devfeed.tech/sources/maskray.md>)

Topics: [LLVM](<https://devfeed.tech/topics/llvm.md>), [Compiler](<https://devfeed.tech/topics/compiler.md>), [reproducible builds](<https://devfeed.tech/topics/reproducible-builds.md>), [hash](<https://devfeed.tech/topics/hash.md>)

Tags: [clang](<https://devfeed.tech/tags/clang.md>), [compiler](<https://devfeed.tech/tags/compiler.md>), [hash](<https://devfeed.tech/tags/hash.md>), [lld](<https://devfeed.tech/tags/lld.md>), [llvm](<https://devfeed.tech/tags/llvm.md>), [reproducible-builds](<https://devfeed.tech/tags/reproducible-builds.md>), [test](<https://devfeed.tech/tags/test.md>)

## AI overview

This article examines how LLVM can develop dependencies on unspecified or incidental behavior under Hyrum's Law, causing output variation that harms reproducible builds, bisection, and bug reports. It describes hash-seed perturbation, reverse container iteration, and iterator invalidation checks as mechanisms for exposing such dependencies.

## Source excerpt

With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody. -- Hyrum's Law In a compiler, the most common form of Hyrum's Law is dependence on unspecified behavior -- hash bucket order, the order of equal elements after std::sort, padding offsets. The same framing covers a few cases that are technically undefined behavior (use of an invalidated iterator) or plain incidental properties (ABI struct layout, ELF section offsets). When the compiler itself harbors such a dependency, the symptom is usually output that varies build-to-build: an unstable sort that lands differently after the standard library changes, a hash map whose iteration order shifts when the hash function does. Occasionally the variation is run-to-run within a single build -- DenseMap<void *, X> keys with an ASLR-derived seed reorder buckets each invocation. Either way, reproducible builds, bisection, and bug reports all assume same input -> same output, and a stealth Hyrum dependency breaks that. This post surveys some mechanisms that perturb the contract's blind spots so dependencies cannot quietly form.