Embedded systems have changed a lot in the last 15 years. But until recently a basic building block – the C language – has not kept up. It’s time to start paying more attention to the newest C11 revision and how to use it.

I have a variety of C books, some of which are really good. Some aren't. And none are complete.

An exploration of the new additions to the C language in C11, starting with concurrency, language-level atomic operations and thread primitives.

C11 specifies many security features that require minimal changes to existing code. They greatly reduce unexpected behavior and prevent many kinds of common attacks.

C11 adds useful, handy features that match some of the additions to C++. However, key divergences mean that a few C11 features have no counterparts in C++.

A detailed discussion of the fragility of the C programming language as it is presented in the new C11 revision, and why some of its ambiguities make it impossible to guarantee any C program will not crash.

What constitutes an effective coding style? Here are six general rules for writing clean code that will help you steer clear of the problems that poor coding style creates.

Self-documenting code? What rubbish!

It's a mistake to place a comment after a line of C or C++

Assertions and other C macros have been of tremendous use to developers in dealing with coding bugs. But why are they still debated especially within embedded designs, where they are of most benefit?

Documenting code is a lot of work, but an essential part of what embedded engineers do and can't be skip it or done half-heartedly. Here are some tricks to make it easier and more complete.

In this six part series, excerpted from a recent book for students, Jack Ganssle deals with the many embedded C-language coding problems and gotchas and provides some helpful hints on how to resolve them. Up first in Part 1: reentrancy, atomic variables and recursion.