C17: reformulations for atomic_flag

In C11, there was a problem with the fact that atomic_flag is one of the rare types that is not considered to have a value, but it only has state (clear and set) which is changed via function calls. (mtx_t and cnd_t are other examples of such types.) There was no established relation between these states and the return value of the atomic_flag_test_and_set functions (which is bool).

C17 clears that up by prescribing the return values of atomic_flag_test_and_set

Continue reading “C17: reformulations for atomic_flag”

Advertisements

C17: rvalues and function types drop qualifiers

At least since C99 the C standard has:

The properties associated with qualified types are meaningful only for expressions that are lvalues.

This phrase expresses the intent that type qualifiers are to be ignored in “some sense” if they appear in other contexts, namely for the values of expressions, i.e. rvalues.

Until the invention of _Generic in C11, nobody really cared what happened to qualifiers of expressions: only the value and size, not the type itself of an expression was observable from inside a C program.

This changed with C11, _Generic makes types observable. Unfortunately the formulation of the _Generic feature itself did not make it clear if it could be used to also detect the qualifications. C11 leaves the following questions unresolved

    1. Are there contexts where qualified rvalues can pop up?
    2. Can _Generic distinguish a qualified argument from an unqualified one?

In particular the lack of clarification of the second question lead to divergence in the implementation of the _Generic feature in mainline compilers.

In our work for C17, we tackled these questions in two “defect reports”, DR 423 (for a.) and DR 481 (for b.).

DR 423

For the first, there are two context that seemed to allow values of expressions to have qualifiers: casts and function returns. For both it was decided that the intent of the standard never had been to have qualifications here, and that the standard should be fixed to clearly state that intent. Therefore DR 423 proposes two modifications. For casts, it changes the first phrase of 6.5.4.p5 (change in red)

Preceding an expression by a parenthesized type name converts the value of the expression to the unqualified version of the named type.

For function returns, the situation is a bit more complicated, because the current syntax allows return types of functions to be qualified. E.g.

double const foo(void) {
    return 0;
}

Is a valid definition of a function. Whenever it is called, the return value is an rvalue, so is this value a double or a double const?

The answer that was found is to treat the above function as if the const where not present. That is, the return type of the function is adjusted to the unqualified type. The proposed change for 6.7.6.3 p5 is

If, in the declaration “T D1“, D1 has the form
D ( parameter-type-list )
or
D ( identifier-list opt )
and the type specified for ident in the declaration “T D” is “derived-declarator-type-list T“, then the type specified for ident is “derived-declarator-type-list function returning the unqualified version of T“.

Beware that this has more effects than just changing the qualification of value expressions. Compilers that will claim to be compliant to C17 must accept the following:

double (*foop)(void) = foo;
double const (*foopc)(void) = foop;

That is any function type or type derived from that behaves as if the qualifier were not present. Most current compilers will probably see these as a constraint violations. Also, since now types that may have been considered different are now clearly specified to be the same, the following expression is a constraint violation:

_Generic(X,
    double (*)(void): 1,
    double const (*)(void): 2
)

because a generic expression is not supposed to have two entries with compatible types. Most current compilers probably would accept that construct, so they’d have to be fixed.

DR 481

For _Generic it was decided that the intent of the construct was to implement some kind of function overloading for C and that it was meant to have a behavior that is the closest possible to that intended feature. So it was decided to force that the type of a controlling expression is seen as if it would undergo the same conversions as arguments to function calls. The proposed text for 6.5.1.1 reads

The type of the controlling expression is the type of the expression as if it had undergone an lvalue conversionnew), array to pointer conversion, or function to pointer conversion. That type shall be compatible with at most one of the types named in the generic association list.

new) lvalue conversion drops type qualifiers.

 

As a consequence the following code is still valid

_Generic(X,
    double: 1,
    double const: 2
)

only that the second association can never trigger. Therefore it would be reasonable for compilers to give a warning diagnostic for such a generic expression.

This does not mean, though, that qualifiers are not observable at all. You just have to put a little bit more effort into it:

_Generic(&X,
    double*: 1,
    double const*: 2
)

This should still work and both associations may trigger depending on whether or not you pass an lvalue that is const qualified or not.

C17

C17 is a “bugfix release” of the C standard. Whereas the intention of the C working group (WG14) has been that this release does not introduce normative changes (but one), it brings a lot of clarifications all over the place. By adopting this version, some features as implemented by some compilers may change if their interpretation of C11 was different because of an unfortunate ambiguity. The schedule for C17 is as follows:

  • Nov. 2017, adoption by WG14, subject to some minor, editorial changes
  • Dec. 2017, integration of these changes and approval by an editorial committee
  • Jan. to Mar. 2018, editorial back and forth with ISO, more editorial changes due to new requirements by ISO and their strict enforcement
  • Apr 2018, ISO sends out the FDIS (final draft international standard) to the national bodies.
  • Apr to June 2018, ballot
  • June or July 2018, publication, see C17

I identified the following list of changes in C17 compared to C11. The whole process of clarifications that have been integrated is transparently documented in what we called “defect reports”. So if you urgently need to know about some of these you should look them up, there.

My intention is to write a post on most of the items to explain my POV of what happened.  In particular, I will try to cite the new versions of the changed text for reference. Because of copyright issues, I will only be able to do that once C17 has been published by ISO. So please be patient and stay tuned.

    • atomics: initialization (7.17.2, 7.31.8), coherence requirements (5.1.2.4), fences (7.17.3 p11), functions or macros (7.17.1 p6), lockfree depends on type (7.17.5 p3), compare exchange compares memory and not value (7.17.7.3), atomic_flag (7.17.18)
    • threads: spurious wakeup (7.26.3.5 p2, 7.26.3.6 p2, 7.26.4.5 p3), synchronization (7.26.4 p1), thread specific storage (tss_t) and thread exit (7.26.5 p3, 7.26.5.5, 7.26.6)
    • _Generic (6.5.1.1), rvalues and qualification, cast (6.5.4)
    • alignment: fundamental alignment (6.2.8), _Alignas (6.7.5), aligned_alloc (7.22.3.1)
    • sequence points: full expressions (6.8 p4), full declarators (6.7..6 p3)
    • infinite loops (6.8.5 p6)
    • reserved identifiers (7.1.3)
    • domain or range errors (7.12.1), ilogb, erfc, lgamma,
    • underspecification of clock (7.27.2.1)
    • underspecification of realloc for size 0 (7.22.3.5)
    • Annex F: FLT_ROUNDS (F.2 p1)
    • Annex K: tmpnam_s, snprintf_s, sprintf_s, vsprintf_s, get_s, mbstowcs_s, wcstombs_s, snwprintf_s, swprintf_s, vsnwprintf_s, vswprint_s, mbsrtowcs_s, wcsrtombs_s

NB: comments are switched off for this post. Please communicate errors or imprecisions that you spotted to me directly. If on the other hand you want to discuss the future (or not) of C, there are a lot of places out there. The best that I know of is WG14 itself. So if you really care, please sign in on your committee of your national standards body for programming languages or alike, and invest yourself in the process.

Improving the specification of arithmetic for atomics

In a document to the standards committee of last year I had observed a set of unfortunate inconsistencies in C11’s specification of arithmetic operations for atomics. As you perhaps know such operations can be specified with operators a++ (in the language part) or generic functions atomic_fetch_add(&a, 1) (in the library), but unfortunately the two parts had not been redacted to fit well in all places.

My new document Minimal Suggested Corrigendum for Arithmetic on Atomic Objects will hopefully make it as proposed corrigendum into the next “bugfix” version of the standard, and hopefully this new version will see the light and the end of 2017. It will perhaps not be with the exact words as they are presented, but I think that the text already comes close to what the intent of the committee had been, and to what implementors actually do, anyhow.

The controlling expression of _Generic

Recently it showed that the C standard seems to be ambiguous on how to interpret the controlling expression of _Generic, the one that determines the choice. Compiler implementors have given different answers to this question; we will see below that there is code that is interpreted quite differently by different existing compilers. None of them is “wrong” at a first view, so this tells us that we must be careful when we use _Generic. In this post I will try to explain the problem and to give you some work around for common cases.

Continue reading “The controlling expression of _Generic”

C11 defects: initialization of padding

The C11 has added an attempt to force compilers to initialize padding of structures and unions under certain circumstances. Unfortunately the situation has become confusing now, since it still foresees that padding can be treated differently from other parts of structures that are not initialized explicitly.

Continue reading “C11 defects: initialization of padding”

C11 defects: C threads are not realizable with POSIX threads

This post is mainly identical to a defect report that hopefully will be discussed by the C standards committee on their next meeting. I found that problem that this raises needs to be better known before people start using this interface more widely, so I decided to also publish it here.

The thread interfaces as they are declared in the threads.h header are largely underspecified, such that interpreting them is often just guess-work and leaves room for a wide range of interpretations. This is particularly irritating since there already is an ISO standard about threads that is quite elaborated and mature, namely ISO/IEC 9945:2009, commonly know as POSIX 2010. C11 mentions ISO/IEC 9945:2009, but completely misses to technically relate to it on the thread interface. The semantic specification of C11 threads is in parts so loose, that a stringent implementation of C11 threads on top of POSIX doesn’t seem possible.

Other platforms that are less formalized than POSIX have their own technical restrictions that should additionally be taken into account. The “other platform” for threads that clearly had been targeted by the committee are threads on Microsoft Windows platforms. Most other widely used commodity operating systems are POSIX compatible (from mainframes down to Android phones). But we should not underestimate the potential of the C threads interface. Because it has a reduced interface it might be suitable for a larger range of platforms than we can foresee today. Because C threads don’t enforce a complete share of the address space, such platforms could e.g be accelerators (providing a portable thread interface on GPU?) or networks on chips. The only memory that must be shared by C threads are objects with static storage duration and objects allocated through malloc and friends. Thus freestanding environments without malloc would only be required to shared statically allocated objects.

In the following I only give an incomplete list of the defects as I noticed them, I suspect that there might be a lot of others.

Continue reading “C11 defects: C threads are not realizable with POSIX threads”