The C Application Binary Interface

WHY IT EXISTS: Once software is compiled into machine code, the original structural cues disappear. A program that wants to use a compiled library cannot see how that library organized its logic before compilation. There needs to be a fixed set of rules for how the program reaches into the library's machine code to invoke behavior or read results. Without this agreement, the consumer would not know where entry points reside or how to pass information at the binary level.

THE MENTAL MODEL: Think of an ABI like the standardized plug and voltage specification between two appliances made by different manufacturers. The library is the power plant producing raw energy in the form of machine instructions. The consumer program is the appliance that wants to tap that energy. The ABI defines the shape of the socket, the voltage, and the sequence for connecting safely. Both sides must conform to the same physical standard or the connection fails, even if both devices are perfectly functional on their own.

HOW IT WORKS: A library exposes an interface that is defined for in-process machine code access. This means the contract operates at the level of raw binary rather than at any higher level of abstraction. The exposing software, typically a library, makes its compiled output available in a predictable arrangement. The consumer, typically a program, uses that arrangement to reach the correct locations and exchange information using the agreed-upon binary format. Everything happens within the same process, so the ABI governs internal access and execution flow rather than external channels.

WHEN TO USE IT: You depend on an ABI whenever you integrate a compiled library into an application and need the two pieces to execute together in a single process. This is the default situation for most compiled software ecosystems where libraries ship as binary artifacts rather than text that gets rebuilt inside the consumer. Any time a program invokes behavior from a separately compiled unit without recompiling that unit from scratch, an ABI is in effect.

WHEN NOT TO USE IT: An ABI is irrelevant when all code is compiled together as one monolithic unit from a single codebase, because no stable public contract is needed between parts that are built simultaneously. It is also unnecessary when communication happens outside of in-process machine code access, such as through human-readable configuration or external messaging, where the boundary is defined by a protocol rather than a binary interface.

ONE CANONICAL EXAMPLE: Consider a library compiled into a binary artifact and a program that wants to use a routine from that library. The library exposes the routine through its ABI. The program knows how to reach that routine because both adhere to the same interface definition. The program does not need anything beyond the compiled binary and the rules of the ABI to access the machine code correctly within the same process.