Header detection and defect work on the Markham C agenda
Markham brings together maintenance of C11 and proposals for the next revision. The header-detection proposal illustrates the practical portability questions behind that work.
Determining whether a header exists is a small portability problem with consequences for shared C and C++ build environments. A configuration script can test for it before compilation, but that answer belongs to the environment where the script ran. A preprocessor predicate can ask the question while translating the actual source. Clark Nelson proposed bringing __has_include to C, partly to keep the two languages' preprocessors synchronized. That proposal appears among the papers for WG14's Markham meeting.
The meeting archive associates Markham with the April meeting week. The more specific N2133 agenda schedules WG14 sessions for April 3 through 6 at IBM's Canada Software Lab. It assigns C-related discussion at the co-located WG23 meeting to April 7. The agenda is useful evidence of the technical work put before the committee, while a listed proposal alone does not establish an adopted language change.
I find this distinction particularly useful for C. A small language can still require substantial maintenance of the rules that make separately written programs and implementations agree. The Markham agenda puts proposals for new facilities beside defect work on the existing standard, so understanding the meeting requires keeping those activities separate.
Asking the translation environment about a header
Nelson's N2101 proposal adapts working-draft changes from the C++ effort to C's conventions. Its introduction presents synchronization between preprocessors as a reason to consider the facility. It also identifies editorial work still needed, making its status as a proposal clear.
The proposed predicate searches for a header or source file as an include directive would. A successful search produces one, and failure produces zero. That result can control conditional inclusion without attempting the include and accepting a missing-header failure as the discovery mechanism.
The following illustrates the proposed use for an application-specific optional header. It assumes an implementation that provides the predicate. It is not a claim that the Markham meeting has made this syntax mandatory for C implementations.
#if __has_include("site_config.h")
# include "site_config.h"
# define HAVE_SITE_CONFIG 1
#else
# define HAVE_SITE_CONFIG 0
#endif
The result answers whether the translation environment can find that file under the include search rules. It does not establish that the header defines a particular function, or that a separately linked library contains an implementation. The mechanism's usefulness depends on asking the question it actually answers. A program whose decision concerns a declaration or linkable symbol still needs evidence about that requirement.
N2101 also describes how defined, #ifdef and #ifndef should treat the predicate's name. That part matters for compatibility code, because recognizing the operator and finding a requested header are different questions. The proposal specifies both the operator's result and its place in conditional preprocessing.
Maintenance continues beside new proposals
The agenda reserves a separate section for defect reports against C11. It lists normal processing alongside new material for particular reports, including replacement wording for DR 501. It separately lists defect work for the secure coding rules specification and the floating-point technical specifications. These are distinct documents with distinct maintenance requirements.
That separation helps explain what a standards meeting can change. A proposal for a new operator asks whether the language should gain a facility. Defect processing asks whether existing wording needs interpretation or correction. The technical discussion may look similar in both cases, but readers cannot infer the status of a rule merely from the fact that the committee discussed it.
Other document-review items show how broad that maintenance work is. The agenda includes hexadecimal floating-point output precision and compatibility of enums, structures and unions within one translation unit. Such questions affect what a portable program can assume about existing facilities. They need precise wording even when they add no new syntax.
Floating-point work has several separate contracts
The agenda's floating-point papers distinguish interchange and extended types from mathematical functions. Other items concern evaluation formats, optimization controls and reproducible results. Those topics belong together operationally, but they describe different promises an implementation might make to a numerical program.
A type's representation does not by itself specify every intermediate evaluation decision. Likewise, a mathematical function's existence does not establish a program-wide policy for reproducibility. The agenda presents separate proposals for these areas, which allows each question to receive its own specification and review. It would be premature to read that collection as a single feature already available to applications.
I prefer standards accounts that preserve those boundaries. The material available for Markham shows concrete questions about preprocessing and numerical behavior, alongside the continued correction of C11. For someone reading a compiler manual or a public header, the practical consequence is to distinguish the implementation's supported extensions from requirements already established by the standard. N2101 offers a precise proposed answer for header detection, while its appearance on an agenda establishes the committee's subject of review rather than the outcome of that review.