On Tue, May 24, 2022 at 06:11:09PM +0000, Joseph Myers wrote: > 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).
Ah, nice (I almost never use our wiki). One more reason to have a single place for such overviews. > 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. Right, so I think it would make sense to have one line for a feature, and add related papers to the second column, as we do in the C++ table: https://gcc.gnu.org/projects/cxx-status.html (see e.g. concepts). > (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.) OK, so I think we should have one feature ("_BitInt") and have those three papers in the "Proposal" column. > 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. For those either we could say "N/A" (gray color), or not mention them at all, though I'd perfer the former. > 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. Notes like these could go to the "Notes" column. > 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). These could be marked as "partially implemented" (yellow color). Except I often don't know which features need extensions like that. > 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). Indeed, and that's a hard problem. I for one could never figure out this one. So I'd leave it in the "?" (red color) state. > > + <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. Probably here we could just say "Yes" (green color) and make a note in the "Notes" column. > 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.) Yeah, I bet. It's tricky to decide :/. > > + <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. Maybe it's just me, but I find some value in having proposals like that in the table too (but it should be "N/A" and gray). This is what I did for N2641. What I like about having a table like this is that it makes it clear what remains to be implemented, and unimplemented features have a linked PR, which makes it easy to see if someone is already planning to implement the feature, or if it still unassigned. Please let me know if you (dis)agree and I can give this another shot (using your notes you provided in the other email). Thanks, Marek
