Welcome to Editor's Report N2598, which is for the Standard N2596 and the related C Working Draft Diffmarks N2597. There weren't as many papers integrated from before but there were still a handful of changes. Some papers were not fully integrated at this time (e.g., Part 3 of the Floating Point TS related to Binary Decimals and more). This is to be expected, given the size of the TS and the amount of work it will take to integrate the entirety of it.
The goal of N2596 was to keep the amount of work down and fix up a lot of editorial mistakes that happened in N2573. To a large degree, with the exception of the Part 3 Floating Point TS and its new Annex, this has been accomplished. We have merged all papers except that one, and handled all recent editorial requests except for changing DN_ prefixes to DECN_. This is because that prefix change only exists in the Part 3 Floating Point TS.
N2596 contains a clear list of all the papers integrated at the last meeting, and before then, as part of its Front Matter.
A lot of papers from a myriad of meetings (some from the October 2019 Ithaca, NY meeting and even before) had to be integrated, in part or in whole. Sometimes, they updated the same area of text in the Standard. Some were approved, and then "new" versions were approved with updated wording at a later meeting. There was a lot of merging and negotiating going into the text of making N2573. There should not be a period of instability of paper updates again for a while, so applying changes in the future should be a lot more straightforward.
That being said, please check over both the diffmarks and the Working Draft itself to make sure the changes you expected from your paper were done properly. We have -- at this point -- had to quintuple check the changes, but it never hurts to have an extra pair of eyes!
The papers that were integrated without issues - as done by following the issue and merge request trackers at the C Standard GitLab Instance - for the October 2020 Virtual Meeting are as follows:
N2546 - Missing DEC_EVAL_METHOD
N2547 - Missing const in decimal getpayload functions
N2548 - intmax_t removal from FP functions
N2549 - Binary Literals
N2552 - Editorial cleanup for rounding macros
N2557 - Allow Duplicate Attributes
N2559 - Update to IEC 60559:2020
N2560 - FP hex formatting precision
N2562 - Unclear type relationship between a format specifier and its argument
N2563 - Character encoding of diagnostic text
N2564 - Range errors and math functions
The following papers were integrated with special directives given by the Committee to reduce/change the scope of their changes in some editorial, on-the-fly manner:
N2571 - snprintf nonnegative clarification
use "both nonnegative" terminology rather than the whole paper
N2570 - Feature and WANT macros for Annex F functions
Use "Example 2" (one-frame, one-WANT macro) solution
The papers that were integrated without issues - as done by following the issue and merge request trackers at the C Standard GitLab Instance - for the November 2020 Virtual Meeting are as follows:
N2572 - What We Think We Reserve
N2580 - Decimal Floating Point Triples
N2586 - Sufficient Formatting Precision
N2594 - Remove Mixed Wide String Literal Concatenation
N2600 - Update to IEC 60559:2020 (updates previously approved version, N2559)
N2602 - Infinity/NAN Macros, Editorial Fixes
N2607 - Compatibility of Pointers to Arrays with Qualifiers
Some papers were approved but will take some time to integrate properly.
N2601: Annex IEC 60559 interchange and extended types (updates previously approved version, N2561)
We expect to have this one ready before the pre-meeting in March 2021!
After doing the full integrations, some editorial changes since before Ithaca were merged into the Standard. Some had already been merged but were lost in history during the transfer of the C sources. The editorial changes that were applied (or re-applied, after some version history shenanigans) were:
Clean up _Bool Expansion macros
There was an extra parentheses and "integer constant" instead of "integer constant expression"!
Fix "A domain error occurs" wording from a few Floating Point functions
There was a few instances of duplicated text in the standard.
Fix __has_c_attribute duplicated text
Thanks for the keen eyes here, Joseph Myers!
Fix a merging error for N2508 - Free Positioning of Labels
There were a few mess ups in merging in the text from N2508 for the [[fallthrough]] attribute. Thanks for catching this one, Martin Uecker!
N2547 - Missing const in decimal floating point getpayload function
This paper is editorial, but was formally submitted so nobody would forget!
N2552 - Editorial cleanup for rounding macros
This was editorial, but a paper was submitted so nobody would forget!
N2562 - Unclear type relationship between a format specifier and its argument
An additional change to make the use of the "a" article consistent on both sides, and the use of the storage word, as approved by the paper author and another comment. Thanks, Aaron Ballman and Robert Seacord!
N2594 - Remove Mixed Wide String Literal Concatenation
The wording was deemed unclear by a few folk and edits were suggested. It was improved from collaboration over the mailing list and a few more tweaks while integrating the paper.
As it stands, when papers are integrated into the Standard what generally happens is references and other thing are updated. Occasionally, some papers add new references to different sections based on their wording. This is all fine, except for the distinct problem that most of those section references are entirely numeric. A lot of the time, this works: the C standard is not moved around in any way that invalidates previous numbers. Very rarely does a section number change, though occasionally paragraph numbers are changed (we don't reference those explicitly, however).
This, unfortunately, does not make editing the standard easier. Numeric section IDs have no reality or correlation to what actually ends up going in the standard. Unless that information happens to be in the head of the editor at the time, section numbers are meaningless and require cross-referencing the actual Standard's document that the TS or Paper was written against, and then translating that version's section numbers.
A much better system would be stable tags. This is a set of short-form identifiers that do not replace Section Numbers, but augment them by being an alternative reference. Each stable tag is a composition of lowercase ASCII a-z, 0-9 characters, plus a dot separating logical sections for ease of reading and memorization. [env.limits.integer] is far easier to know where it is going than 5.2.4.2.1.
This will likely be proposed in a future Editorial paper.
There was some discussion about how many things were being pushed as editorial fixes; some felt like making editorial changes was rushing things and not allowing the Committee to do its job. To clarify, things that are considered editorial can be but are not limited to:
intended fixes that an author forgot to add to their paper (e.g., they edited one section of the standard, but another section with nearly identical wording was not updated and it is unambiguously clear to both Committee and Paper Author that they intended it);
typos and clearly incorrect terminology; and/or,
mistakes made in integrating the paper.
This does not mean any of the above changes will be done at-will; in most cases, the Committee will be consulted if there is a problem or an ambiguity.
For example, the SNAN changes integrated during this cycle originally appeared to be simple, but as several Committee members and the CFP group pointed out over time, there were numerous more changes that needed to be made to other sections. At that point, the issue stopped being editorial: the Editors asked the C Floating Point group to write a paper, which they did. Any time the scope of changes goes beyond very basic clarification, correction, and improvement on obvious intent, Editors will direct the folks in question to write a paper.
In some cases, the Committee already had discussion but the change is still significant enough to warrant notification. This means that even if the change is made, a message is sent both directly to the stake holders and to the Committee at large. For example, this happened with an atomic footnote addition (as noted in the last editor's report). Despite the change being editorial and it being agreed it was editorial in the Ithaca, NY meeting, a message was sent to the entire Committee after confirming with both the issue submitter and its resolution giver that the resolution was correct. If someone _had_, then a paper would have been requested (nobody did).
Even after a change is made, this does not mean there is no communication or no chance to notice said change. Asides from Diffmarks of the standard being made available and all changes being listed in the Working Draft itself, these editor reports contain a full list.
All changes -- editorial and not -- are fully documented in an Editor's report, along with its reasoning. If any such change is found to be "too broad" or similar, all one has to do is message an editor and make that clear. Because this is a working document and not a standard, changes can (and will) be rolled back if there is a legitimate, serious objection to how it arrived in the Standard. Albeit, we note that changes voted into the Standard would generally require a paper to remove them, whereas editorial issues just require messaging the editors or anyone connected to the editors.
Finally, part of this is built on being able to trust that your editor can tell the difference between an editorial issue and something which is "Evolutionary" and needs Committee attention/consensus. It's also realizing that the editor has a responsibility -- when an issue is brought to them -- about what is the appropriate response. There is a serious trade off between
sending a message to the editor asking them to take care of something;
sending a message to the editor, asking them to take care of something and having the Committee at large notified with a message of the change to be sure to proceed; or,
doing all of the below:
go through a National Body (e.g., pay your National Body for membership or be part of a company that does);
make yourself available for an in-person/virtual meeting during any business day of that C Standard Meeting's week;
request a paper number from the WG14 Secretariat;
write the paper with the requisite front page, introduction, motivation, and more; and
presenting said paper for the Committee to go over and change.
Papers are a heavy investment. They demand a lot of time from both the Submitter, and the Committee at large. Asking someone to write a paper to change a typo or fix the single use of an expression is overkill, and drains valuable volunteer energy out of our community when we need people willing to do much larger, more systemic changes to our Standard. It is Good and Necessary stewardship to take every concern seriously and weigh it against its merits and impact. Anything not small obviously needs to go in front of the Committee, and any change editors are not comfortable with making directly -- which is a lot of things as editors tend to be extremely conservative in their approach to document editing -- will be directed to the appropriate channels.
Papers are still to be submitted in the old fashion, but work has begun on a new paper system for WG14 to enable the Committee to:
iterate faster on papers;
upload and view papers faster; and
be able to establish a proper history for visiblity.
To this end a new paper system is being worked on. When it's ready, it will likely appear at the Shepherd's Oasis Website. We are using purely open source tools and distributed version control to allow for not only paper revisions but paper history, thanks to Git Large Filesystem (Git LFS). The focus of the system will be new papers, before historical papers (N-numbered) get pulled into the system too. The hope is to unveil the very first alpha of this system in Mid-February and -- Murphy's Law being kind and permitting -- hopefully in use in the meeting after that!
Thank you for contributing to and working on the C Standard!
— JeanHeyd Meneide, Project Editor <wg14@soasis.org>