[Dwarf-discuss] Proposal: C standard release dates for DW_AT_language_version, clarify semantics

[Adrian Prantl]

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 <jakub@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