{"id":390778,"date":"2024-06-29T09:26:43","date_gmt":"2024-06-29T09:26:43","guid":{"rendered":"http:\/\/savepearlharbor.com\/?p=390778"},"modified":"-0001-11-30T00:00:00","modified_gmt":"-0001-11-29T21:00:00","slug":"","status":"publish","type":"post","link":"https:\/\/savepearlharbor.com\/?p=390778","title":{"rendered":"C2x: the future C standard<\/span>"},"content":{"rendered":"
<\/div>\n
\n
\n
\n
\n

\"image\"<\/p>\n

<\/p>\n

I strain to make the far-off echo yield
A cue to the events that may come in my day.
(\u2018Doctor Zhivago\u2019, Boris Pasternak)<\/p><\/blockquote>\n

I\u2019ll be honest: I don\u2019t write in pure C that often anymore and I haven\u2019t been following the language\u2019s development for a long time. However, two unexpected things happened recently: \u0421 won back<\/a> the title of the most popular programming language according to TIOBE, and the first truly interesting<\/a> book in years on this language was published. So, I decided to spend a few evenings studying material on C2x, the future version of C.<\/p>\n

<\/p>\n

Here I will share with you what I consider to be its most interesting new features.<\/p>\n

<\/a> <\/p>\n

The Committee, the Standard and all that<\/h1>\n

<\/p>\n

I am sure most of you know how C is developed, but, for anyone who doesn\u2019t know let me first explain the terminology, and will then briefly retell the story of the language.<\/p>\n

<\/p>\n

In 1989 the already extremely popular programming language, C, reached new heights of recognition, becoming both the American national (ANSI<\/a>) and the international (ISO<\/a>) standard. This version of C was known as C89, or ANSI C to differentiate it from the numerous semi-compatible dialects that had existed previously.<\/p>\n

<\/p>\n

A new version of the language standard is released approximately once every ten years. At the present time there are four versions in existence: the original C89, C99, C11 and C18. It is not known when the next version will be published, so the version currently being worked on is referred to as C2x.<\/p>\n

<\/p>\n

Changes to the standard are made by a special group, the so-called WG14. It comprises interested representatives of the industry from various countries.<\/p>\n

<\/p>\n

In the specialist English-language literature this group is often referred to as the \u2018Committee\u2019, so that is what I am going to call it here as well.<\/p>\n

<\/p>\n

The Committee receives proposals from those involved, each proposal being given a designation(e.g. N2353<\/a>). Proposals usually include: the reason for introducing changes, references to other documents, and specific changes to the Standard. Proposals can come in several versions, each of which is given a unique designation.<\/p>\n

<\/p>\n

Returning to our topic for a moment, I have split this article into three parts, and have ordered them according to the likelihood of the relevant changes being made to the standard. The three parts are as follows:<\/p>\n

<\/p>\n

    \n
  1. Proposals the Committee has already accepted.<\/li>\n
  2. Proposals received positively but returned to the authors for revision.<\/li>\n
  3. What I consider to be the \u2018juiciest\u2019 proposals: rumoured unpublished proposals, being discussed behind the scenes by members of the Committee.<\/li>\n<\/ol>\n

    <\/p>\n

    Proposals accepted by the Committee<\/h1>\n

    <\/p>\n

    strdup and strndup functions<\/h3>\n

    <\/p>\n

    I may appear ignorant when I say that I wasn\u2019t aware these functions weren\u2019t in the standard C library. What could be more obvious and simpler than copying strings? But no, C isn\u2019t like that. C doesn\u2019t like its users.<\/p>\n

    <\/p>\n

    So, 20 years later, we are getting<\/a> the strdup<\/code> and strndup<\/code> functions!<\/p>\n

    <\/p>\n

    #include <string.h>  char *strdup (const char *s); char *strndup (const char *s, size_t size);<\/code><\/pre>\n
      <\/p>\n
    It is nice to know that even the Committee accepts the inevitable.<\/p>\n
      <\/p>\n
    Attributes<\/h3>\n
      <\/p>\n
    Developers of major C compilers have a favourite game they play: coming up with extensions to the language most often expressed through attributes of declarations and definitions. The language itself, of course, does not provide any special syntax for such things, so each person needs to do what they can to be creative.<\/p>\n
      <\/p>\n
    In order to \u2013 somehow \u2013 to sort out this mess without coming up with dozens of new keywords, the Committee thought up a syntax-to-rule-them-all. In a nutshell, a standard syntax<\/a> for specifying attributes will be approved as part of the next version. Here is an example from the proposal:<\/p>\n
      <\/p>\n
    [[attr1]] struct [[attr2]] S { } [[attr3]] s1 [[attr4]], s2 [[attr5]];<\/code><\/pre>\n
      <\/p>\n
    Here, attr1<\/code> relates to s1<\/code> and =s2=<\/code>; attr2<\/code> relates to the struct S<\/code> definition; attr3<\/code> relates to the struct s1<\/code> type; attr4<\/code> to the s1<\/code> identifier; and attr5<\/code> to the s2<\/code> identifier.<\/p>\n
      <\/p>\n
    The Committee has already voted to include the attributes in the standard, but there is still a long time to wait before the updated version of the standard is published. Nevertheless, proposal authors are already playing with their new toy. Here are some of the proposed attributes:<\/p>\n
      <\/p>\n
      \n
    1. The deprecated<\/code> attribute allows you to mark a declaration as obsolete, which allows compilers to issue appropriate warnings.<\/li>\n
    2. The fallthrough<\/code> attribute can be used to explicitly mark the places in the switch case branches, where the control flow is supposed to cross case boundaries.<\/li>\n
    3. Using the nodiscard<\/code> attribute you can explicitly specify that a value returned by the function needs to be processed.<\/li>\n
    4. Where a variable or function is not used deliberately, you can mark it with the maybe_unused<\/code> attribute (instead of the idiomatic (void) unused_var<\/code>).<\/li>\n
    5. A function not returning to the call location can be marked with the noreturn<\/code> attribute.<\/li>\n<\/ol>\n
        <\/p>\n
      Old-school function parameter declaration style (K&R)<\/h3>\n
        <\/p>\n
      \u2018K&R declaration\u2019 (read \u201cwhen types are specified after the brackets\u201d or, \u201cI don\u2019t understand old code in C\u201d) is a form of function parameter declaration that was already out-of-date way back in 1989. It is finally going to be burnt with fire<\/a>. In other words, you won\u2019t be allowed to do this anymore:<\/p>\n
        <\/p>\n
      long maxl (a, b) long a, b; {     return a > b ? a: b; }<\/code><\/pre>\n
        <\/p>\n
      Enlightenment has finally come to code in C! Function declarations will at last actually do what people expect them to:<\/p>\n
        <\/p>\n
      \/* function declaration without arguments *\/ int no_args();  \/* also function declaration without arguments *\/ int no_args(void);<\/code><\/pre>\n
        <\/p>\n
      Signed integer representation<\/h3>\n
        <\/p>\n
      What has felt like an endless saga is nearing completion, it would seem. The Committee has come to terms<\/a> with the fact that there are no such things as unicorns or mythical architectures, and programmers in C are dealing with Two\u2019s complement<\/a> signed integer representation.<\/p>\n
        <\/p>\n
      In its present form this clarification simplifies the standard a little, but in future it should make it possible to get rid of the language\u2019s favourite undefined behaviour.<\/p>\n
        <\/p>\n
      Proposals being worked on<\/h1>\n
        <\/p>\n
      While it can be said that the changes listed above already exist in our reality, the following group of proposals is still being developed. Nevertheless, the Committee has given them provisional approval and, assuming the authors show due diligence, they should definitely be accepted.<\/p>\n
        <\/p>\n
      Anonymous function parameters<\/h3>\n
        <\/p>\n
      I regularly write 1-2 trial programs in C a week. And, quite honestly, I have long grown tired of having to specify the names of unused arguments.<\/p>\n
        <\/p>\n
      Implementing one<\/a> of the proposals positively assessed by the Committee would mean that we wouldn\u2019t have to keep specifying the names of parameters in function definitions:<\/p>\n
        <\/p>\n
      int main(int, char *[]) {     \/* No hassle! *\/     return 0; }<\/code><\/pre>\n
        <\/p>\n
      It\u2019s a small thing \u2013 but welcome!<\/p>\n
        <\/p>\n
      The old new keywords<\/h3>\n
        <\/p>\n
      After a very loooong transition period the Committee, finally, decided to accept, erm, \u2018new\u2019<\/a> keywords<\/a> into the language: true<\/code>, false<\/code>, alignas<\/code>, alignof<\/code>, bool<\/code>, static_assert<\/code> and others. It will finally be possible to drop headers like <stdbool.h><\/code>.<\/p>\n
        <\/p>\n
      Including binary files in the source file<\/h3>\n
        <\/p>\n
      The option<\/a> of including binary data from files in the executable file is something all game developers are going to find unbelievably useful:<\/p>\n
        <\/p>\n
      const int music[] = {    #embed int \"music.wav\" };<\/code><\/pre>\n
        <\/p>\n
      It\u2019s my belief that the Committee has realises that the community knows where their next meeting is being held, and that this preprocessor directive will be accepted without questions.<\/p>\n
        <\/p>\n
      Farewell, NULL \u2013 or nullptr ready on the starting blocks<\/h3>\n
        <\/p>\n
      It would seem that the problematic NULL<\/code> macros are being replaced<\/a> with the keyword nullptr<\/code>, which will be equivalent to the expression ((void*)0)<\/code> and, in the case of type conversion, will have to remain a pointer type. Any use of NULL should be accompanied with a compiler warning:<\/p>\n
        <\/p>\n
      \/* I always forget why the cast is necessary. *\/ int execl(path, arg1, arg2, (char  *) NULL);  \/* But happiness is just round the corner *\/ int execl(path, arg1, arg2, nullptr);<\/code><\/pre>\n
        <\/p>\n
      If this example make no sense to you, then take a look at the Linux documentation under man 3 exec<\/code> and you will find your enlightenment there.<\/p>\n
        <\/p>\n
      Reform of error processing in the standard library<\/h3>\n
        <\/p>\n
      The processing of standard library function errors has been a longstanding problem in C. The combination of unfortunate solutions in various versions of the standard, the conservative stance of the Committee and reverse compatibility issues have all got in the way of finding a solution that suits everyone.<\/p>\n
        <\/p>\n
      And here, finally, is someone prepared to propose<\/a> a solution for compiler developers, the super-conservative Committee and for us mere mortals:<\/p>\n
        <\/p>\n
      [[ oob_return_errno ]] int myabs (int x) {   if(x == INT_MIN ) {           oob_return_errno ( ERANGE , INT_MIN ) ;   }   return (x < 0) ? -x : x; }<\/code><\/pre>\n
        <\/p>\n
      Let me draw your attention to the oob_return_errno<\/code> attribute. This means that the following functions will be generated from this template function:<\/p>\n
        <\/p>\n
        \n
      1. A function returning the structure with an error flag and the result of the work of the (struct {T return_value; int exception_code}<\/code>) function.<\/li>\n
      2. A function returning the result of the work of the function, and ignoring possible errors in the arguments, leading to undefined behaviour.<\/li>\n
      3. A function terminating execution in the case of an error in the arguments.<\/li>\n
      4. A function replacing errno, that is, exhibiting ordinary behaviour.<\/li>\n<\/ol>\n
          <\/p>\n
        The compiler is offered a choice between these options, depending on how the programmer uses a given function:<\/p>\n
          <\/p>\n
        bool flag; int result = oob_capture(&flag , myabs , input) ; if (flag) {     abort ();<\/code><\/pre>\n
          <\/p>\n
        In this case, if the function has been carried out properly, this is shown with a flag, while errno is not affected. Function calls saving the error code to the variable, for example, look similar.<\/p>\n
          <\/p>\n
        The actual syntax, it would seem, will yet change, but it is a good thing that the Committee is at least thinking<\/em> in this direction.<\/p>\n
          <\/p>\n
        Rumours<\/h1>\n
          <\/p>\n
        The author of \u201cEffective C\u201d, along with other Committee members, answered<\/a> questions from members of the Hacker News community. Lots of things overlap with what we have noted above. But there are a couple of points which are important for programmers. These have not been formulated as proposals, as such, however Committee members are hinting that work might be underway in these areas.<\/p>\n
          <\/p>\n
        typeof operator<\/h3>\n
          <\/p>\n
        The typeof<\/code> keyword was implemented<\/a> a long time ago in compilers and makes it easier to write correct macros. Here is a textbook example:<\/p>\n
          <\/p>\n
        #define max(a,b)                                \\     ({ typeof (a) _a = (a);                     \\     typeof (b) _b = (b);                        \\     _a > _b ? _a : _b; })<\/code><\/pre>\n
          <\/p>\n
        Martin Sebor, a developer from Red Hat and a Committee member, maintains that a relevant proposal is already being worked on and will very likely be approved.<\/p>\n
          <\/p>\n
        Keeping my fingers crossed!<\/p>\n
          <\/p>\n
        defer operator<\/h3>\n
          <\/p>\n
        Some programming languages, including ones implemented by Clang and GCC, allow you to bind freed-up resources to the lexical scoping of variables or, to put it more simply, to call given code when the control flow goes outside the scope of the variable.<\/p>\n
          <\/p>\n
        Pure C doesn\u2019t have this option nor ever has, but compilers have been implementing the cleanup(<cleanup function>)<\/code> attribute for a long time:<\/p>\n
          <\/p>\n
        int main(void) {    __attribute__((cleanup(my_cleanup_function))) char *s = malloc(sizeof(*s));    return 0; }<\/code><\/pre>\n
          <\/p>\n
        Robert Seacord author of \u201cEffective C\u201d and member of the Committee has admitted<\/a> that he is working on a proposal along the lines of the keyword defer<\/code> from Go:<\/p>\n
          <\/p>\n
        int do_something(void) {     FILE *file1, *file2;     object_t *obj;     file1 = fopen(\"a_file\", \"w\");     if (file1 == NULL) {       return -1;     }     defer(fclose, file1);      file2 = fopen(\"another_file\", \"w\");     if (file2 == NULL) {       return -1;     }     defer(fclose, file2);      \/* ... *\/      return 0; }<\/code><\/pre>\n
          <\/p>\n
        In this example, the fclose<\/code> function will be called with the file1<\/code> and file2<\/code> arguments, in any case where the program goes outside the body of the do_something<\/code> function.<\/p>\n
          <\/p>\n
        Vive la r\u00e9volution!<\/p>\n
          <\/p>\n
        Conclusions<\/h1>\n
          <\/p>\n
        Changes to C are like genetic mutations: they don\u2019t happen often, rarely are viable, but, in the end, they push the evolution forward.<\/p>\n
          <\/p>\n
        The most recent unfortunate changes to C occurred ten years ago. And the most recent quality leap forward in terms of development of the language happened over 20 years ago. And, by all accounts, the members of the Committee have now decided to consider moving forwards in respect of the new iteration of the standard.<\/p>\n
          <\/p>\n
        So, to conclude: use static analysers, run Valgrind as often as possible and try not to write overly-big programs in C!<\/p>\n
          <\/p>\n
        PS<\/strong> I think the \u201cfirst truly interesting book\u201d thing was an overstatement on my part. Someone recommended a book entitled \u2018Modern C\u2019<\/a> written by a member of the committee, and that would definitely be worth a read.<\/p>\n<\/div>\n<\/div>\n<\/div>\n
        <\/div>\n

         \u0441\u0441\u044b\u043b\u043a\u0430 \u043d\u0430 \u043e\u0440\u0438\u0433\u0438\u043d\u0430\u043b \u0441\u0442\u0430\u0442\u044c\u0438          https:\/\/habr.com\/ru\/articles\/512802\/<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"
        <\/div>\n
        \n
        \n
        \n
        \n
        \"image\"<\/p>\n
          <\/p>\n
        I strain to make the far-off echo yield
          A cue to the events that may come in my day.
          (\u2018Doctor Zhivago\u2019, Boris Pasternak)<\/p><\/blockquote>\n
        I\u2019ll be honest: I don\u2019t write in pure C that often anymore and I haven\u2019t been following the language\u2019s development for a long time. However, two unexpected things happened recently: \u0421 won back<\/a> the title of the most popular programming language according to TIOBE, and the first truly interesting<\/a> book in years on this language was published. So, I decided to spend a few evenings studying material on C2x, the future version of C.<\/p>\n
          <\/p>\n
        Here I will share with you what I consider to be its most interesting new features.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[],"tags":[],"class_list":["post-390778","post","type-post","status-publish","format-standard","hentry"],"_links":{"self":[{"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=\/wp\/v2\/posts\/390778","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=390778"}],"version-history":[{"count":0,"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=\/wp\/v2\/posts\/390778\/revisions"}],"wp:attachment":[{"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=390778"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=390778"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=390778"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}