Small allocations and alignment on the Pittsburgh C agenda

The alignment promised by malloc becomes a disputed question when the requested allocation is smaller than the alignment itself. David Goldblatt's N2293 describes two readings of the C wording and proposes to allow the weaker requirement explicitly. The paper appears on the Pittsburgh agenda, whose meeting runs October 15 through 18 in the WG14 schedule.

This is an account of the submitted question and its supporting evidence. The agenda establishes its place in the meeting's work, but does not establish how the committee resolved it. The proposal concerns a guarantee already interpreted differently by existing allocators, so understanding those interpretations is useful independently of the eventual wording decision.

C matters to me as a reference for layout and interoperability. A promise about a pointer's alignment is part of that practical contract. Here the difficulty is that a sentence intended to describe suitable storage can imply a stronger property for tiny allocations than the objects they could contain actually require.

Two readings of the same allocation promise

Goldblatt calls the first interpretation strong alignment. It requires returned storage to satisfy _Alignof(max_align_t) even when the requested size could not hold an object with that alignment. The alternative, weak alignment, requires enough alignment for the relevant types that can inhabit the requested storage.

The paper grounds the distinction in the relationship between a portable type's size and alignment. For such a type T, sizeof(T) is at least _Alignof(T). A request too small to hold T therefore need not, under the weak reading, provide the alignment needed for T. Goldblatt expresses the small-allocation requirement in terms of the largest power of two no greater than the requested size.

The disputed standard sentence says that a successfully returned pointer is suitably aligned for an object with a fundamental alignment requirement and can then access that object in the allocated space. Strong-alignment readers treat the alignment promise as independent of whether the object fits. Weak-alignment readers interpret the allocated-space qualification as limiting the types to which the promise applies.

Goldblatt does not try to resolve the disagreement through grammatical certainty. His argument is that implementers have read the wording both ways in good faith. The practical decision is therefore which existing behavior to permit unambiguously and what cost a different decision would impose.

The proposed edit makes size part of the contract

N2293 proposes adding an explicit size qualification. The returned pointer must support objects with fundamental alignment requirements whose size is no greater than the requested allocation. A following sentence then describes access to an object or array in that storage.

This change would permit both groups of implementation. An allocator that already supplies stronger alignment could continue to do so. The proposal would not require it to reduce alignment. It would instead make that stronger guarantee something the implementation can document beyond the standard's minimum requirement.

The distinction can be expressed without assigning a numeric alignment to a particular machine:

#include <stddef.h>
#include <stdlib.h>

void inspect_alignment(void)
{
    void *small = malloc(1);
    size_t fundamental_alignment = _Alignof(max_align_t);
    (void)fundamental_alignment;
    free(small);
}

These declarations ask different questions. The allocation requests one byte, while the alignment expression describes the platform's fundamental alignment. Under the proposal, the request alone would not establish that the returned address satisfies the latter expression's value. A larger alignment guarantee would need a separate justification.

The example does not use the pointer to access a larger object. Allocated size remains a separate limit even if an implementation happens to return a strongly aligned address. Alignment cannot supply storage that the allocation did not request. Keeping those properties separate avoids turning a discussion of pointer alignment into an implied permission to overrun an allocation.

Existing allocators already make different choices

Goldblatt's survey places glibc, the macOS library, musl and OpenBSD in the strong-alignment group. It places the Windows CRT and several jemalloc-based libraries in the weak-alignment group, along with other allocators. He qualifies the survey as his best account based on experiments, source inspection and consultation with maintainers.

That qualification matters because the paper is evidence about implementation practice, not a guarantee for every future build of those libraries. Goldblatt also identifies himself as a jemalloc maintainer. His performance argument comes from an implementation for which the stronger requirement would require changes, and the paper makes that perspective explicit.

The survey gives a concrete portability argument. Code relying on strong alignment for a small allocation already needs an implementation that supplies it. Clarifying the standard in the weak direction would acknowledge the behavior of other existing implementations. It would not suddenly create the observed divergence.

I find that implementation inventory more persuasive than an argument based solely on the wording's intended grammar. A useful minimum contract has to account for the allocators programs actually encounter. The question is whether demanding a stronger minimum buys enough useful behavior to justify changing those implementations.

Alignment can impose a minimum allocation cost

The paper describes several mechanisms behind the cost. A stronger alignment requirement can increase the minimum size of a returned region. With boundary tags, Goldblatt says the effective minimum allocation size can become twice _Alignof(max_align_t). That is an allocator-layout consequence, not a statement that every allocation scheme pays the same amount.

Size classes introduce another effect. Allocators can use object size as a lifetime heuristic and group storage accordingly. Collapsing tiny requests into a larger minimum class can reduce the distinctions available for reuse. In concurrent allocators that shard locks by size class, forcing more requests through one small class can also increase contention.

N2293 includes measurements, but their scope remains specific. Goldblatt reports results for two proprietary server processes and a separate public-source compiler workload. They support his claim that the requirement can have measurable cost. They do not establish one universal percentage for all applications or all allocators.

The paper also examines possible breakage, including pointer tagging and casts to more strongly aligned types. Its code searches did not identify a portable program that needed the disputed extra guarantee. That is a bounded search result, not proof that no such program exists. The proposed contract would leave implementations free to document a stronger guarantee where their users require one.