83

As I was checking news about GCC 8, I saw that they added support for the 2017 version of the C language (not C++17, really C17). But I can't find any information about it on Internet.

Is it a new ISO version like C11, or just a codename used by the GCC team for some corrections in their compiler ?

msc
  • 33,420
  • 29
  • 119
  • 214
informaticienzero
  • 1,796
  • 1
  • 12
  • 22
  • 3
    You are only allowed to publish up to a certain number (two?) of technical corrigendum (TC) to an ISO standard. If you need to make further correction after having already released x number of TC, a new version of the standard has to be released. I suspect that is the case here. – Lundin Nov 29 '17 at 13:46
  • 3
    @Lundin: There were three TCs for C99 (incorporated into [N1256](http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf)). It's possible the rules have changed since then. – Keith Thompson Apr 20 '18 at 15:50

2 Answers2

67

According to GCC reference, C17 is actually a bug-fix version of the C11 standard with DR resolutions integrated.

C17, a bug-fix version of the C11 standard with DR [Defect Report] resolutions integrated, will soon go to ballot. This patch adds corresponding options -std=c17, -std=gnu17 (new default version, replacing -std=gnu11 as the default), -std=iso9899:2017. As a bug-fix version of the standard, there is no need for flag_isoc17 or any options for compatibility warnings; however, there is a new __STDC_VERSION__ value, so new cpplib languages CLK_GNUC17 and CLK_STDC17 are added to support using that new value with the new options. (If the standard ends up being published in 2018 and being known as C18, option aliases can be added. Note however that -std=iso9899:199409 corresponds to a __STDC_VERSION__ value rather than a publication date.)

(There are a couple of DR resolutions needing implementing in GCC, but that's independent of the new options.)

So, there are no new features included in C17.

The Cppreference (History of C) says:

Future development

C17 Next minor C language standard revision, will include all accepted C11 defect reports, but no new features.

UPDATE:

  • 2018: C17 (ISO/IEC 9899:2018) (ISO Store) (Final draft) Includes the deprecation of ATOMIC_VAR_INIT and the fixes to the following defect reports:

[DR 400], [DR 401], [DR 402], [DR 403], [DR 404], [DR 405], [DR 406], [DR 407], [DR 410], [DR 412], [DR 414], [DR 415], [DR 416], [DR 417], [DR 419], [DR 423], [DR 426], [DR 428], [DR 429], [DR 430], [DR 431], [DR 433], [DR 434], [DR 436], [DR 437], [DR 438], [DR 439], [DR 441], [DR 444], [DR 445], [DR 447], [DR 448], [DR 450], [DR 452], [DR 453], [DR 457], [DR 458], [DR 459], [DR 460], [DR 462], [DR 464], [DR 465], [DR 468], [DR 470], [DR 471], [DR 472], [DR 473], [DR 475], [DR 477], [DR 480], [DR 481], [DR 485], [DR 487], [DR 491]

Sadeq Dousti
  • 3,346
  • 6
  • 35
  • 53
msc
  • 33,420
  • 29
  • 119
  • 214
  • 3
    Then it's published by ISO, but it's just a bug-fix version. Thanks ! – informaticienzero Nov 28 '17 at 11:06
  • 13
    Just to complement that, there is actually one effective change proposed: the use of `ATOMIC_VAR_INIT` is no more mandatory for the initialization of atomic variables. Plain normal initialization suffices. – Jens Gustedt Nov 28 '17 at 13:12
  • 31
    For those who aren't used at reading standard gibberish: DR stands for Defect Report. – Lundin Nov 29 '17 at 13:32
  • 1
    Does C17 yet unambiguously define the behavior of code that uses an aggregate member lvalue to access the storage of the aggregate? In every version to date, something like `struct foo {int x;} s = {0}; s.x = 3;` would write the storage associated with a `struct foo` using an lvalue of type `int`, but `int` is not one of the lvalue types that may be used to access a `struct foo`. – supercat Apr 25 '18 at 17:34
  • 5
    The C17 standard is now available for purchase, although I'm not sure why ANSI has raised the price approximately 93% from $60 to $116. https://webstore.ansi.org/RecordDetail.aspx?sku=INCITS%2fISO%2fIEC+9899%3a2011+(R2017) – m0j0 Apr 26 '18 at 15:49
  • @supercat I'm not sure I understand what you're saying. To what ambiguity are you referring? Are you implying that the expression `s.x = 3` is undefined behavior for some reason? –  Sep 08 '18 at 15:47
  • @ChronoKitsune: The way N1570 6.5p7 is actually written, such a statement would violate a runtime constraint--and thus yield UB--unless member `x` is a character type. I think the authors of the Standard assumed that compiler writers would handle such cases sensibly whether or not the Standard required them to do so, and for that particular case they seem to be right. A good standard, however, shouldn't rely upon such treatment in a day and age where compiler writers regard as insist that they have no obligation to avoid breaking code whose behavior isn't actually mandated by the Standard. – supercat Sep 08 '18 at 23:38
  • Fundamentally, N1570 p6.5p7 fails to offer any guidance as to how to reliably determine between actions which compilers should be expected to process reliably and those they shouldn't. Since there are some cases where code should have clearly defined behavior but violates the constraint in by 6.5p7, the fact that a construct violates 6.5p7 cannot be regarded as a reliably indication as to whether compilers should process it meaningfully. As it is, gcc and clang seem to treat the rule as "Treat violations as UB except when that'd be so mind-numbingly dumb as to make people throw out 6.5p7"... – supercat Sep 09 '18 at 00:00
  • ...but that's really not a good recipe for distinguishing defined and undefined behavior. – supercat Sep 09 '18 at 00:02
  • @supercat I think I'm still missing some piece of the puzzle. 6.5.2.3p3 states that the expression `s.x` has the value stored in subobject `x` of object `s` and also states that it's an lvalue because `s` is an lvalue, so by extension `s.x` also is an lvalue. The effective type (6.5p6) of `s.x` is the declared type of the object: `int`. In the case of `3`, the effective type is `int`. One of the requirements of 6.5p7 states that only an lvalue expression with a type compatible with the effective type of the object is allowed to access it. `(int) = (int);`, so I don't see the problem. –  Sep 09 '18 at 00:26
  • @ChronoKitsune: If the assignment to `s.x` were only regarded as accessing the stored value only of an object of type `int`, and not of a `struct foo`, then `s.x` should be accessible via any lvalue of type `int`, including those of the form `pointerToStructWithCommonInitialSequence->x` but neither gcc nor clang allow that. The only justification for gcc and clang to optimize there would be if an access to an `int` member of `s` is also an access to a `struct foo`, but that would imply that an access using lvalue `s.x` is only allowed because a compiler opts not to be stupid. – supercat Sep 09 '18 at 03:38
  • @supercat You lost me at `pointerToStructWithCommonInitialSequence`. How is your original example without pointers ambiguous? There are no pointers or a common initial sequence involved in `s.x = 3;` so how is it a constraint violation? In what way is `s.x` not simply an `int`? –  Sep 09 '18 at 04:59
  • @ChronoKitsune: An access to a structure member is *also* an access to the enclosing structure object, and vice versa. While N1570 gives blanket permission to use lvalues of the enclosing structure type to be used to access members, the blanket permission is (IMHO deliberately) not reciprocal. I think the clear intention is that a `struct foo` should be accessible via lvalues of type `int` in some circumstances, but I see nothing in N1570 that would identify any circumstances where such accesses wouldn't violate the constraints of 6.5p7. It sounds like C17 is the same way. – supercat Sep 09 '18 at 16:50
  • @supercat Ah, I think I understand what you're saying finally. You're suggesting that `s.x` itself is UB because 6.5p7 only permits you to access object `s` using a type compatible with its own effective type `struct foo` (i.e. only `struct foo`) or an aggregate or union type that includes such a type among its members, meaning you cannot access `s` using its member `x`. In other words, you believe the rules expressed in 6.5p7 contradict the allowed behavior and syntax specified by 6.5.2.3, so `s.x` is ambiguous. –  Sep 09 '18 at 22:39
  • While you're clearly accessing member `x`, you're also accessing `s` with a type of `int` rather than its only compatible effective type `struct foo`, implying that you cannot ever declare a structure containing a member with a type other than that structure's own type if you ever hope to use it. Simply put, 6.5p7 was created with good intentions, but it fails to achieve its goal and instead makes things more difficult. –  Sep 09 '18 at 22:40
  • @ChronoKitsune: If compilers only applied 6.5p7 in cases that where lvalues *alias* lvalues of other types which are used to object the same storage (which is hinted at by the non-normative footnote) there would be no problem. It's been obvious for years, however, that some compiler writers want to apply the rules even in cases which don't involve cross-type aliasing as written, making the Standard's lack of precision a major problem. – supercat Sep 10 '18 at 04:05
36

C17 is a “bugfix release” of the C standard how "M.S Chaudhari" noticed. However, there is very useful information prepared by Jens Gustedt the author of "Modern C" book.

He identified the following list of changes in C17 compared to C11:

Link to the main page C17.

Also, this content will be updated by Jens you can follow to update here Jeans Gustedt Blog.

P.S: before posting all this stuff I received approval from the author.

Nick S
  • 1,299
  • 1
  • 11
  • 23
  • 2
    Very neat book; thanks. It's like an open-access, more systematic, in-depth version of Klemens's _21st Century C_. – Geremia Dec 05 '18 at 03:07