Jens Gustedt's Blog

August 22, 2013

testing compile time constness and null pointers with C11’s _Generic

Filed under: C11, C99, language, P99, preprocessor, syntax — Jens Gustedt @ 13:23

Sometimes in C it is useful to distinguish if an expression is an “integral constant expression” or a “null pointer constant”. E.g for an object that is allocated statically, only such expressions are valid initializers. Usually we are able to determine that directly when writing an initializer, but if we want to initialize a more complicated struct with a function like initializer macro, with earlier versions of C we have the choice:

  • Use a compiler extension such as gcc’s __builtin_constant_p
  • We’d have to write two different versions of such a macro, one for static allocation and one for automatic.

In the following I will explain how to achieve such a goal with C11’s _Generic feature. I am not aware of a C++ feature that provides the same possibilities. Also, this uses the ternary operator (notably different in C and C++), so readers that merely come from that community should read the following with precaution.



July 15, 2013

a praise of size_t and other unsigned types

Filed under: C11, C99, integers, language — Jens Gustedt @ 16:17

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.


February 4, 2013

Runtime-constraint violations

Filed under: C11, library — Jens Gustedt @ 08:30

Somewhat hidden in Annex K, C11 introduces a new term into the C standard, namely runtime-constraint violations. They offer an important change of concept for the functions that are defined in that annex: if such a function is e.g called with invalid parameters, a specific function (called runtime-constraint handler) is called, that could e.g abort the program, or just issue an error message. This is in sharp contrast to the runtime error handling in the rest of the C standard, where the behavior under such errors is mostly undefined (anything may happen then) or sometimes reported to implementation defined behavior (and thus poorly portable and predictable).

Annex K, obscurely coined “Bounds checking interfaces“, introduces some typedef and a series of replacement functions for many C library functions. The function names in this series are usually derived from the name of the function they replace and by adding the suffix _s to the function name, e.g the function qsort gets a “secure” twin interface called qsort_s, as we have seen in an earlier post.


December 4, 2012

inline functions as good as templates

Filed under: C11, C99, compiler optimization, library — Jens Gustedt @ 23:24

I recently started to implement parts of the “Bounds checking interfaces” of C11 (Annex K) for P99 and observed a nice property of my implementation of qsort_s. Since for P99 basically all functions are inlined, my compilers (gcc and clang) are able to integrate the comparison functions completely into the sorting code, just as an equivalent implementation in C++ would achieve with template code.


November 21, 2012

P99 futexes: non-blocking integer valued condition variables

Filed under: C11, C99, linux, lock structures, P99, POSIX — Jens Gustedt @ 12:18

A while ago I already have written about Linux futexes as a really nice concept for a control data structure that goes beyond the ones that we learn or teach in school (mutex, semaphore, condition variable…). I have now gone one step further and integrated futexes into P99; if used on Linux this will evidently use the corresponding Linux feature under the hood, on other platforms a C11 thread implementation using mutexes and condition variables can be used.

One of the real disadvantages of most of the control structures is that they have two very different kinds of events: user events (e.g a call to cnd_signal) and system events, often called “spurious wakeups”. Unless we program system code, these spurious wakeups are just an annoyance. They are easily forgotten during development and lead to subtle bugs that only appear on heavy load or when changing the platform and handling them often makes the user code overly complex.

p99_futex are designed to work around this type of problems, by still providing a close integration of the control structure into the system and by efficiently distinguishing a “fast path” for operations from a “slow path” where we handle congestion. They provide a counter similar to a conditional variable that allows atomic increments and to wait for it, just as the Linux system call does. (Only that for ideological reasons the base type is an unsigned, instead of an int as in Linux.)


October 24, 2012

C11 defects: initialization of padding

Filed under: C11, C99, defects, language — Jens Gustedt @ 21:55

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.


October 14, 2012

C11 defects: C threads are not realizable with POSIX threads

Filed under: C11, defects, language, POSIX — Tags: — Jens Gustedt @ 21:19

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.


August 17, 2012

named constants

Filed under: C11, C99, feature request, language — Jens Gustedt @ 11:48

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 };


July 15, 2012

Capture return codes from library functions

Filed under: C11, C99, library — Jens Gustedt @ 21:57

C (and POSIX) library functions often communicate error conditions in a two stage procedure: first the return value of the function is set to a special value (such as 0 for malloc) and then the caller can read the particular error condition from the pseudo-variable errno.

This “traditional” error handling has several disadvantages:

  • Code that captures all returns from library functions with conditional code quickly becomes unreadable. Optically such code emphasizes on the error handling part, instead of the normal control flow.
  • errno is a fragile thing, and in particular after it has been set by a transient error, it must be reset to 0.

P99 now lets you overload functions with appropriate macros for the error check, and that if an error occurs will either abort execution or throw an error via P99’s P99_TROW.


July 11, 2012

Drop out: there is not opt out button for dropbox

Filed under: rants — Jens Gustedt @ 06:51

Recently someone sent me a “share” request on dropbox and used one of my email addresses that is not yet linked to that service, and for which I don’t want to ever use dropbox. I then redirected that person to use another mail account for that, and the person did. Everything fine, so far.

But then days later dropbox kindly reminded me that there was this request pending. I guess that spam would have gone on for a while, if I hadn’t stopped it.

So I went to the dropbox site to opt out of their service for this particular email. It took me a while to realize that the expectation that there might exist just a little button for that was far too naive, there is no such thing on their site. I am sure that technically such a button would not be much of a problem, basically just the same as subscribing for such a service. (You’d have to verify the email, somehow.)

So I had to go through their “help” system, which took actually two entire days until I got through to a human. Finally they put that mail address on a black list.

In summary not too good an experience as a “non-user”. I already would rate the services that they offer to real customers relatively bad:

  • pro: a file sharing service, even free of charge for all the use I had for now
  • contra: ridiculous management of access rights:
    • it allow your “friends” to inadvertently delete your files when “moving” them on their laptop disk, instead of copying them
    • It allows your friends to silently accumulate GigaBytes of files on your hard disk, by collecting files in shared directories that basically are never cleaned up. (currently 3.4 GiB on my hard disk)
  • contra: no encryption or data protection

I will probably think again before I send an “invite” to share some files on dropbox, this might be a real privacy intrusion.

« Newer PostsOlder Posts »

Create a free website or blog at