Submitter: AUTHOR NAME
Submission Date: DATE
SummaryWhat is the problem, source of confusion, etc. with the standard. Please cite the relevant unclear/conflicting sections of the standard, for example,
In 6.7.4p6, inline functions are allowed, yet are not required to have external linkage.
A reference to
code should be so marked, and one can in , or this way, as you see fit. As another option, you can choose to provide emphasis this way.
At times, it is best to provide examples or other commentary, particularly when quoting, using
This section of text is set off from the rest in a simple and concise manner, and is appropriate for small sections of code or otherwise quoted text. As with all uses of HTML, there are no exact guidelines for what will make your case compelling.
Suggested Technical Corrigendum
When ready, get an official document number "Nxxx" from the WG14 Convener, John Benito, email@example.com, add it to the title, and submit the document to him. The committee will do its best to review this document at its next meeting. The meeting schedules can be found here.
The committee process is generally to do a quick evaluation of your "Nxxx" document and accept your concern as a defect on initial review and recompose this document and issue it with a defect report number (e.g. DR_4xx). It will be discussed, and a summary of the discussion and direction are recorded in the DR_4xx report (as well as the meeting report). If in fact the committee decides that the document does not reflect a defect, the committee will provide a Proposed Committee Response explaining why. Otherwise, the committee will eventually prepare a Proposed Technical Corrigendum with initial status Open, and will eventually move the status to Review, then Closed, and eventually Published. The status is found in summary.htm. Please review the proposed resolution and possibly provide more input if you find it unsatisfactory from a technical viewpoint.
Thank you for your efforts to improve the Standard!