Revised proposal based on feedback from Jakub! # 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 199901 C11 201112 C17 201710 C23 202311 Add the following non-normative wording: Producers that implemented language features of an upcoming unreleased revision of a language with a YYYY or YYYYMM versioning scheme should pick a date that is greater than the latest release, but not in the future. Consumers that want to convert a YYYY or YYYMM version number to a specific release, should treat all version numbers in the range (A, B] as belonging to release B. ## Dependencies Issue 210419.1 ## References https://iso-9899.info/wiki/The_Standard https://dwarfstd.org/languages-v6.html > On Apr 24, 2024, at 3:08 PM, Jakub Jelinek via Dwarf-discuss > <dwarf-discuss@lists.dwarfstd.org> wrote: > > 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 -- Dwarf-discuss mailing list Dwarf-discuss@lists.dwarfstd.org https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss
