The C2y draft makes editorial changes inspectable

The WG14 document log lists N3886, the pre-Ottawa working draft, on May 24. The draft itself collects the language and library specification as C2y develops after C23. Its value for an engineer is partly the ability to follow a proposed change into its surrounding text. A proposal explains a local revision, while the working draft shows how that revision interacts with the rest of the specification.

C was my first language, and I have used it for thirty years. I still regard knowing the boundary of defined behavior as an essential part of writing it well. Reading a working draft is useful when a familiar rule has changed or when a compiler diagnostic refers to wording I need to examine. I am especially interested in the editorial work that makes those rules interpretable, because an ambiguous example can affect how someone reads a much more formal paragraph.

A draft records integration history

N3886 includes a chronological account of integrated changes. It traces C2y work after C23 and identifies the papers associated with successive meetings. The most recent section covers the March virtual meeting. Among the entries are implicit constexpr for certain integer declarations and changes involving constant evaluation. This front matter makes it possible to distinguish a feature already represented in the collected text from a separate proposal still being discussed.

The draft is a working document, so I would cite its paper number when discussing a rule. A statement that merely refers to C2y can become ambiguous as the text changes. The numbered document lets another reader locate the same wording and compare it with the proposal that motivated it. That is useful when reporting a compiler issue whose interpretation depends on a particular stage of the standardization work.

The accompanying editor report, N3887, says the changes since the preceding post-February-March draft are editorial. That qualification is important for interpreting this publication. The cumulative working draft contains language evolution, while this particular update also performs the detailed maintenance needed to keep that text consistent. I would not describe every correction in the report as a new language facility.

Examples need the same care as normative wording

The report identifies problems in enumeration examples involving overflow. One enumeration constant now uses USHRT_MAX + 1u, and another example gains a comment acknowledging possible overflow. This is a small change with a specific purpose. A worked example should not teach readers to infer arithmetic behavior that its chosen expression does not support.

I would treat that kind of correction as relevant to documentation derived from the standard. An example often becomes the part a programmer remembers or copies into a compiler experiment. If a tutorial reproduces an older version without checking the surrounding rule, it can preserve the problem after the committee text has corrected it. The editor report provides a direct place to identify those revisions before updating explanatory material.

That does not mean an editorial correction changes every program resembling the example. The report describes a correction to the explanation, and the program still needs to be assessed against the applicable language rules. I would compare the old example with the corrected one before attributing a compiler behavior change to this draft. The distinction keeps an explanation of the standard separate from a claim about an implementation.

Terminology controls how rules connect

The report also changes references to typeof inputs from arguments to operands. The reason is concrete. typeof and the related constructs are operators, so their inputs should use the terminology employed for operators. Consistent terminology helps a reader connect the local wording with rules elsewhere that refer to operands.

Array terminology receives similar attention. The editor found remaining uses of size where the draft intended length expressions or array length expressions. I care about that distinction when explaining memory interfaces because byte sizes and element counts are different quantities. The report does not announce a new allocation mechanism, but it makes the document more consistent about which quantity a particular expression describes.

Several corrections concern the unary-expression form of static_assert. The report describes general wording repairs around that form, along with a missing space in the constant-expression clause. These changes illustrate why a draft needs an editor report even when it adds no new facility since its predecessor. The collected text must remain readable enough for implementers to determine exactly which expression categories a rule covers.

Library text also needs cross-reference repairs

The floating-point changes include renaming a parameter from n to p in the ldexp family and aligning related annex text. The report also adds wording that identifies the return type of certain floating conversion functions. Those repairs concern correspondence between descriptions, declarations and annex material. A reader should not have to guess whether differently named parameters identify different concepts.

The report corrects the record of an SNAN change in the annex describing differences from C23. The previous text attributed the change to two headers even though one was the source of the addition and the other involved deprecation. That matters to anyone using the differences annex as an upgrade guide. The annex needs to describe what changed with enough precision to direct a reader to the right header contract.

Other repairs include table labels and consistent spelling of analogs. These are ordinary editorial tasks, but their accumulation affects whether the draft can support precise technical discussions. A table label is part of a reference, so a wrong label can make an otherwise accurate explanation difficult to follow. I would use the report to identify which references deserve rechecking in material written against the previous draft.

For a compiler experiment, I would record the relevant N3886 clause alongside the specific implementation version and language mode. If the result differs from the text, the report helps establish whether the issue concerns a changed rule, a corrected example or a reference that moved. That gives a bug report a narrower question for the implementer to answer and makes the experiment reproducible against the same draft.