On Wed, Apr 24, 2024 at 02:57:17PM -0700, Adrian Prantl wrote:
>
>
> > On Apr 24, 2024, at 2:49 PM, Jakub Jelinek <ja...@redhat.com> wrote:
> >
> > On Wed, Apr 24, 2024 at 02:25:37PM -0700, Adrian Prantl via Dwarf-discuss
> > wrote:
> >> # C standard release dates for DW_AT_language_version, clarify semantics
> >>
> >> ## Background
> >>
> >> The list of languages at https://dwarfstd.org/languages-v6.html does not
> >> list release dates for the ISO C standard. Producers need to know what
> >> version numbers they should produce though. I scanned the ISO website for
> >> appropriate dates to use.
> >>
> >> ## Proposed Changes
> >>
> >> Augment the table of language encodings to add
> >> C (K&R and ISO) DW_LNAME_C 0x0003 0 YYYYMM
> >>
> >> K&R 000000
> >> C89 198912
> >> C99 199912
> >> C11 201112
> >> C17 201806 (sic!)
> >> C2x >201806
> >
> > That is not correct.
> > C99 199901
> > C11 201112
> > C17 201710
> > C23 202311
>
> Thanks for correcting these! Do you happen to have a link to the source you
> used to look these up?
E.g. the C23 standard?
M.2 Fifth Edition
Major changes in this fifth edition (__STDC_VERSION__ 202311L) include:
...
M.3 Fourth Edition
There were no major changes in the fourth edition (__STDC_VERSION__ 201710L),
only technical
corrections and clarifications.
M.4 Third Edition
Major changes in the third edition (__STDC_VERSION__ 201112L) included:
...
M.5 Second Edition
Major changes in the second edition (__STDC_VERSION__ 199901L) included:
...
M.6 First Edition, Amendment 1
Major changes in the amendment to the first edition (__STDC_VERSION__ 199409L)
included:
The intent is for C versions which do have __STDC_VERSION__ to match that
macro, similarly for C++ versions which do have __cplusplus macro of the
YYYYMM form to match that macro. The dates in there are when the standard
has been voted in (usually it takes then a few months to get officially
released as ISO standard).
> >> This way consumers can emit version numbers for unreleased upcoming
> >> specifications, by using, e.g., the date the compiler was built.
> >
> > That is not a good suggestion.
> > If a compiler supports some part of e.g. C23 but not everything, it should
> > be something larger than 201710 but smaller than 202311, even when the date
> > the compiler was built could be 202404 or later.
> > GCC and Clang up to 17 used e.g. 202000 for C23 partial implementations,
> > GCC still does, Clang 18+ now uses 202311.
>
> That is what I had in mind, but I didn't think about a compiler built after a
> standard was released. Do you have a suggestion for a better wording to
> capture that nuance?
Compilers should simply choose some number which will be known to be later
than the latest released standards and expected to be smaller than the
upcoming standard. E.g. using YYYY of the last standard + 1 and MM of 00
is a good practice, but DWARF shouldn't enforce that.
Consumers aware of just C17 release should simply check for 201710 if
testing about exactly C17, or > 201710 if testing for something later than
that.
Jakub
--
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss
