Jens Gustedt's Blog

September 7, 2016

Ease the transition between C standards

Filed under: C11 — Jens Gustedt @ 16:22

With this post I will start to discuss a series of modifications of the C standard that I have (or will) propose for C2x. As a starting point there is the observation that the passage from one C standard to the next  was not easy in the past. This, neither for implementers of C compilers nor for users, because it was not easy to capture partial improvements. Basically for gcc, e.g., you had to add -std=c11 or similar, and then test for the version number to see if a particular feature is implemented. This task then was even more complicated because some of the new features are language, and some are library.

This was tedious and error prone, and I think we should avoid such difficulties in the future.

So for the next version I propose to relax the constraints on C standard header files. I think we should add a feature test macro for each header that reflects the C version which is completely implemented by this header.

Most headers of the C standard are currently optional, either because they provide an optional feature such as threads or atomics, or because an environment may be free standing. Having feature test macros implies that we then can require that all headers are mandatory. If the feature is not supported by the platform, the only contents of such a header would be the feature test macro, set to 0.

It would be nice if the transition to the next standard could just start by this: everybody provide all standard headers, eventually empty but for the test macro.

For the interested you can find my proposal here:

Mandatory C library headers
simplify the transition to a new C standard

Advertisements

3 Comments »

  1. Interesting proposal. A different way to do this would be to introduce different #include behavior. If we had a “#ifninclude ” that behaved much like #ifndef, couldn’t we do everything in your proposal without adding all the header files? It would also lend itself to handling includes with different names on different platforms. If the include file was not found, then we would do some other step.

    #ifninclude
    #define __STD_ATOMIC__ 0
    #endif

    Or, doing the testing I was talking about:

    #ifninclude
    #ifninclude
    #define OOPS (1)
    #endif
    #endif

    The idea would be that if the include fails to find the file, we have a fallback. In the first case, we note that we do not have atomics. In the second, we try to use a different header file instead. Perhaps it could be extended to behave more like an #if statement or even be made to be part of extended #if syntax:

    #if include
    … do things with atomics …
    #else
    … do things without atomics …
    #endif

    Just an idle thought I had…

    Comment by Kyle Hayes — December 22, 2016 @ 17:46

  2. Hello Kyle,
    thiere is already a similar feature as you propose that will probably in C++17 and that now also has been proposed for C:

    http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2101.htm

    I think that both approaches can be complementary.
    Jens

    Comment by Jens Gustedt — December 22, 2016 @ 19:40

  3. Hmm, I did not get an email from WordPress.

    Interesting. It is pretty much what I was suggesting, except fleshed out and actually viable 🙂 I hope that makes it into C. Thanks for the link!

    Comment by Kyle Hayes — January 11, 2017 @ 19:25


RSS feed for comments on this post.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Create a free website or blog at WordPress.com.