Optional C facilities need consistent feature-test rules

A feature-test macro set to zero does not mean the same thing for every optional C facility. Some specifications interpret its value, while others ask only whether it is defined. Joseph Myers's N2174 paper brings those inconsistencies to WG14 as a request for direction. They affect the declarations a program sees and the names it may define for itself.

This work appears on the Albuquerque agenda, which schedules the meeting from October 30 through November 3. The meeting archive identifies the same week. The agenda also lists a proposed C17 final draft and ongoing defect reports. Those are separate activities from deciding the conventions for optional facilities in future specifications.

I find optional-library rules particularly relevant to C's role in shared interfaces. A public header can change what later includes expose, and independently written components need a consistent environment. The spelling of a macro is easy to see. Its precise effect on the translation unit can be harder to infer.

Defined and enabled are different questions

Myers compares the rules for __STDC_WANT_LIB_EXT1__ with those for other optional specifications. For Annex K, zero suppresses the facilities and one requests them. Leaving the macro undefined gives the implementation a choice, while other values have no specified semantics. That is a value-sensitive interface.

The related __STDC_WANT_LIB_EXT2__ convention differs when the macro is absent. In that case, absence acts like zero, rather than leaving declaration visibility implementation-defined. Even two similarly named request macros therefore differ on what an untouched build environment means.

The floating-point technical specifications use a different model in the account given by N2174. Following the cited defect resolution, presence or absence matters at the first relevant header inclusion. A definition of zero does not suppress the facility, because the macro is still defined. A generic configuration generator that writes zero for disabled options cannot assume that convention works for these macros.

The distinction can be illustrated with two different states. This fragment names one of the macros discussed in the paper without claiming that every optional macro follows its rules.

#define __STDC_WANT_IEC_60559_TYPES_EXT__ 0
/* The macro is defined, despite its zero value. */

Removing that definition creates a different state under a presence-based rule. Changing zero to one does not create the same distinction. The paper's proposed consistency work matters because the apparent configuration value alone is insufficient to identify the requested library environment.

Include consistency affects implementations too

N2174 also examines Annex K's requirement for identical definitions across affected header inclusions. Myers points out that a strict reading can require checking repeated inclusion of the same header. That conflicts with the common implementation technique of skipping a header whose contents have already been processed.

The word identical raises another question. A token sequence of 1 and a token sequence of 1L express equal numerical values for this purpose but are not identical tokens. Myers notes that diagnosing such a change may require implementation machinery that other standard features do not need. A rule intended to make application configuration consistent can therefore impose an unexpectedly specific preprocessor burden.

His suggested direction is a presence-based convention with a consistent set of macros across relevant inclusions, without requiring a diagnostic for violating that consistency. The document asks WG14 for preferred semantics instead of supplying final wording. It is therefore evidence of a proposed direction, not proof that every existing optional facility already behaves that way.

Reserved names are part of the interface

The paper separately asks when optional facilities reserve identifiers with external linkage. Merely hiding declarations does not fully answer whether an application may define an unrelated function with the same name. Declaration visibility and reservation are different properties.

Myers examines wording that reserves the collection of Annex K external names if a program uses any of them. Read literally, use of an identifier for an unrelated application function could appear to trigger the reservation. That makes the permission to use otherwise unreserved names difficult to interpret.

His preferred account distinguishes using a library function from providing an application definition, while also avoiding conflicting declarations and simultaneous use of the optional collection. Similar questions reach other technical reports and the relationship among the floating-point specifications. A consistent answer needs to say which collection of names becomes reserved and what program action causes it.

I prefer making those rules explicit before relying on optional facilities in a shared header. The Albuquerque agenda places this question beside maintenance of the existing standard, showing how future library work depends on decisions about preprocessing and linkage. N2174 identifies the concrete choices that remain, including whether zero has meaning and whether exposing one group of functions reserves names from another group. Those choices determine how separately written components can share one C translation environment.