On Tue, 24 May 2022, Marek Polacek via Gcc-patches wrote: > I thought it'd be nice to have a table that documents our C support > status, like we have https://gcc.gnu.org/projects/cxx-status.html for C++. > We have https://gcc.gnu.org/c99status.html, but that's C99 only. > > So here's a patch to add just that. For C99, I used c99status.html but > added paper numbers (taken from https://clang.llvm.org/c_status.html).
For C11, see https://gcc.gnu.org/wiki/C11Status (note: I haven't checked the accuracy of that page). Listing in terms of features is more useful than listing in terms of papers. Referring to the original paper, even if it's the version that got accepted into the standard, is liable to be actively misleading to anyone working on the implementation; sometimes the paper has multiple choices of which only one was accepted into the standard, or only some of the listed changes were accepted, or there were various subsequent features or fixes from various subsequent papers. (By way of example, it would make more sense to list _BitInt as a single entry for a missing feature than to separately list N2763 and N2775 (accepted papers), while N2960, to be considered at the July meeting of WG14, makes further wording fixes but can't exactly be considered a feature in a sense that should be listed in such a table.) Lots of papers are just cleanups, or clarification of wording, or fixes to issues with previous papers, such that it doesn't make sense to list them as implemented or not at all. As usual there are also cases where a feature is implemented to the extent relevant for conformance but e.g. more optimizations (such as built-in functions) could be added. And cases where some support in GCC should definitely be done to consider the feature implemented, even when not needed for conformance (e.g. the %wN, %wfN printf/scanf formats need implementing in glibc, and corresponding format checking support needs implementing in GCC). There are also cases where a feature is substantially there but a more detailed review should be done for how it matches up to the standard version (e.g. the DFP support based on TR 24732-2009 could do with such a detailed review for how it matches C2x requirements). > + <tr> > + <td>Binary literals</td> > + <td><a > href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2549.pdf";>N2549</a></td> > + <td class="supported"><a href="../gcc-11/changes.html">GCC 11</a></td> > + <td></td> > + </tr> This is an example of cases where the version where a feature was supported in GCC as an extension is long before the version where -pedantic knows about it being supported in a given standard version; listing the version with the -pedantic change in such cases may not be very helpful without noting when it was originally implemented. There are probably other examples in the list. (There are also examples where GCC supports the feature but hasn't yet had -pedantic updated accordingly, e.g. #warning. And cases where it's largely supported but there are small differences in the standard version that still need implementing, e.g. typeof.) > + <tr> > + <td>What we think we reserve</td> > + <td><a > href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2572.pdf";>N2572</a></td> > + <td class="unsupported">?</td> > + <td></td> > + </tr> This is an example of the many cases where it doesn't make sense to consider something as a feature with an "implemented" or "not implemented" state at all - so it doesn't belong in such a table at all. There are many other such examples in the list. -- Joseph S. Myers jos...@codesourcery.com
