View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
00019721003.1(2024)/Issue8Shell and Utilitiespublic2026-01-28 13:382026-01-28 13:38
ReporterLove4Boobies Assigned To 
PrioritynormalSeverityEditorialTypeEnhancement Request
Status NewResolutionOpen 
NameBogdan Barbu
Organization
User Reference
SectionXCU
Page NumberIntroduction
Line NumberN/A
Interp Status
Final Accepted Text
Summary0001972: Determinism in POSIX Utilities
DescriptionThis ticket concerns determinism in POSIX utilities: the property that, for a given implementation, invoking a utility with the same declared inputs (options, operands, input files, and specified environment) yields the same observable results.

This property is increasingly important in modern software development and distribution practices, including artifact signing, verification, auditing, and what is commonly referred to as reproducible builds. Many widely used systems and projects rely on deterministic tool behavior as an implicit assumption when building software and producing distributable artifacts, including: Arch Linux, Debian, Fedora, openSUSE, FreeBSD, NetBSD, GNU Guix, Tor, etc.

The intent of this proposal is not to address interoperability between different systems or implementations. Rather, it concerns intra-implementation behavior. In particular, running the same utility with the same options, operands, input files, and relevant environment on the same system should not produce different results due to undeclared or arbitrary factors such as the current time or date, process identifiers, randomness, or unrelated filesystem state, except where such behavior is explicitly permitted by the specification.

For example, invoking:

    c17 foo.c

is not expected to produce identical output across different systems or implementations. However, invoking the same command multiple times on the same system with the same inputs should not result in observably different output solely due to nondeterministic implementation choices. On the flip side,

    c17 foo.c bar.c

and

    c17 bar.c foo.c

should be allowed to produce different results if the implementation so chooses.

This proposal is concerned with utilities whose output formats or behaviors are partially or fully unspecified by POSIX, yet for which deterministic behavior is reasonably expected. Examples include, but are not limited to, ar, c17, delta, lex, pax, and yacc.
Desired ActionThe following text is proposed to be added to the XCU Introduction.

Deterministic Behavior of Utilities

For a given implementation of a utility, the observable results of an invocation shall be a deterministic function of the utility’s declared inputs.

The declared inputs of a utility consist of:
    a) the options and operands specified on the command line, including their order, except where this standard specifies that order is not significant;
    b) the contents and relevant attributes of any input files read by the utility;
    c) the environment variables specified by this standard as affecting the utility’s execution; and
    d) any configuration files or other external inputs that are specified by this standard as affecting the utility’s execution.

Observable results include, but are not limited to:
    a) data written to standard output and standard error;
    b) exit status; and
    c) the contents and attributes of any files created or modified by the utility.

A conforming implementation shall not cause the observable results of a utility invocation to vary based on other external state, including but not limited to the current time or date, process identifiers, randomness, or unrelated filesystem state, except where such dependence is explicitly specified or permitted by this standard.

Where this standard specifies that aspects of a utility’s output or behavior are unspecified, such behavior shall nevertheless be deterministic for a given implementation and set of declared inputs, unless explicitly stated otherwise.

This requirement does not imply that observable results are required to be identical across different implementations or across different versions of the same implementation.
TagsNo tags attached.

Activities

There are no notes attached to this issue.

Issue History

Date Modified Username Field Change
2026-01-28 13:38 Love4Boobies New Issue