Re: [wwwdocs] Add C status page

[Marek Polacek <polacek@redhat.com>]

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