a praise of size_t and other unsigned types

Again I had a discussion with someone from a C++ background who claimed that one should use signed integer types where possible, and who also claimed that the unsignedness of size_t is merely a historical accident and would never be defined as such nowadays. I strongly disagree with that, so I decided to write this up, for once.

What I write here will only work with C, and can possibly extended to C++ and other languages that implement unsigned integer types, e.g good old Pascal had a cardinal type.

Continue reading “a praise of size_t and other unsigned types”

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”

named constants

It is now exactly two years that I wrote about the underestimated register keyword in C. Today I’d like to tell about an idea that is spinning in my head ever since, that register variables in file scope would be a perfect tool to offer a feature that is much missed in C: named constants of arbitrary data types.

The whole of it is a bit technical, be warned, but the essence of it will be to declare something like the following in a header file, without creating linkage or “instantiation” problems, and helping us to write readable and debuggable code:

register const double PI = 3.14159265358979323846;

typedef struct listElem listElem;
struct listElem { unsigned val; listElem* next; };

register const listElem singleton = { 0 };

Continue reading “named constants”

type generic functions taking pointers or arrays

Every C programmer knows about the implicit conversion an array object A undergoes in most contexts: it is converted to a pointer to its first element, as if the programmer had written `&A[0]`. The technical term of the standard for that is “lvalue conversion”, and the corresponding section describes what precisely is going on when an object (an lvalue) is evaluated for its contents (the rvalue).

One particular place where this conversion takes place is when an array is passed as an argument to a function. So in that case all additional information about the array, in particular its length, is not made available to the function. One could always pass the size of the array (sizeof A) as additional argument to the function, but this then would always require to pass this information also in case the function is called with what its interface suggest, just a pointer. In this post I will describe a new possibility that is provided by the _Generic keyword in C11 that allows us to create type generic interfaces that knows how to distinguish between the case being called with an array or with a pointer as an argument.
Continue reading “type generic functions taking pointers or arrays”

C11 defects: underspecification of tss_t

Section 7.26.6 “Thread-specific storage functions” of C11 is severely underspecified since it uses terms that are not introduced (so far) in the context of C. This is really a pity, since POSIX also has pthread_key_t that is completely feature equivalent and for which the specification is much more complete.

Jacob Navia had observed that at several occasions in comp.std.c but it seems that he had not got enough attention such that this had made it in a defect report.

Continue reading “C11 defects: underspecification of tss_t

C11 defects: initialization of atomic_flag

With this post I will be starting some random collection of things that I consider being defects of the C11 standard. Perhaps someone of the committee could pick them up or send me a mail to discuss them and eventually formulate a formal defect report.

C11 expresses the intention to have atomic_flag as a primitive that should allow to emulate all other atomic types and operations, 7.17.8 p3 in a note says:

The remaining types can be emulated with atomic_flag, though with less than ideal properties.

Continue reading “C11 defects: initialization of atomic_flag