标签: c11

In the continually changing world of embedded systems design in the era of ubiquitous connectivity, where no device is an island unto itself, one thing remains constant: the popularity of the C language for use in space and resource constrained applications.   While C++ has become popular for consumer mobile and wearable apps and in the enterprise, in both traditional embedded systems and the minimalist IoT environment of MCU-based machine-to-machine and wireless sensor networking, the C language or some variant of it remains king.   But the challenges of new environments mean our tools must be used in new ways and new capabilities must be added. The C language has evolved and a variety of features have been added ad hoc, but the ISO approved standard version of the language has been slow to change. Up until recently the last major revision was C99, in 1999, after which the computing industry, and especially embedded systems, has been turned upside down.   But in 2011 that changed when preliminary implementations of a new version - C11 – were made public with a number of improvements, many in the form of acceptance of features that were found in various compilers already used across a number of platforms, and in its use of better memory models to support multiple threads of execution. C11 has also added five more keywords to the existing 32 in C99 and now includes a number of enhancements:   Multiple threading support Static assertions Strict type enforcement Macros for complex values Alignment specification Type generic expressions Unicode support Bounds-checking interfaces, and Anonymous structures and unions   For a variety of reasons, though, C11 has been slow to migrate into embedded applications. Some of you don't want to rock the board: you've finally gotten a handle on the existing version of the language and do not want the uncertainty of what implementing the new standard would involve. Some of you say it is due to the fact that the compiler you use does not support C11. Others look at C11 as a formalization of techniques and methods already implemented ad hoc within the industry in the existing older compilers and do not think it is worth the time and effort to upgrade.   Despite all these rationalizations, Jack Ganssle recently decided to look at the new finalized version of C11 revision in much more detail. He waded through the long, dry prose of the standard's documentation and found a lot to like. He reports on what has got him excited in “ Why you the C standard is necessary . "   "The C11 standard is over 700 pages. It’s practically unreadable," he writes. "It is one of the driest and most boring books ever to hit the street, so it's unsurprising so few of us have read it, or even flipped through the pages."   But he writes that he was pleasantly surprised to find that it is full of valuable information and insights that the more accessible C books seem to miss. One of the things he is most excited about is the amount of attention it devotes to the assert () macro, something he and others have written about extensively on Embedded.com, despite the fact that the last C99 revision said nothing at all about it this important C language feature.   He found a lot more that interested him and feels that it if you can afford it you should pay to get a copy of the new C11 standard , so you will have what he calls a “foundational document" for the work you will be doing in the future.   "As professionals, we all owe it to ourselves, and to our careers, to have easy access to the foundational documents of our industry," he writes. "And we need to read them!"   It is easy to forget why you do certain things after you have done them so long they have become automatic. And when dealing with a problem child like the C language, even with its improvements, I find it useful to go back and review the basics. there is so much that is useful in the language but also much that can go wrong. So like pilots on commercial aircraft who constantly go over procedures they already know by heart, it is worth regularly going over the fundamentals of the language and how to use it well.   What tools and techniques do you use to make sure your C code is as efficient and as useful as it can be? Have you looked at C11 and incorporated its many improvements into your current coding? If not, why not? Are there resources you have found on the Web that are helpful? I would like to hear from you and get your perspective. Maybe we can work together to put your experiences into writing to share what you have learned with the rest of the embedded systems developer community.

The wind was howling, the rain torrential. I estimated peaks of 80 knots. Storms, even short summer thunderstorms, are always fun, and we were watching the trees wave from a window overlooking the back yard. When the rain let up I changed windows to get a different perspective. A smile formed; I called Marybeth over and pointed to the neighbor’s tree that had fallen onto the barn, crushing the structure. Since moving here five years ago we had a long-term plan to replace the building, its dirt floor and leaky steel siding not really what we wanted. The insurance settlement wasn’t enough for a new barn, but will make a big dent in the costs. We talked through our ideas about the new building, scribbled some crude drawings to get a sense of what would work, and then did not break out the drawing board. Instead, I bought a copy of the International Residential Code. The IRC is a mind-numbingly-dull 900 pages of rules and regulations about every aspect of residential design. Many rail against what is perceived as communitarian prescriptions that at times make little sense, or that are just so completely anal one wonders what the committees were smoking. But tilting at windmills is hardly productive, and the inspectors will certainly fail our work if we try to circumvent the IRC’s rules. The code is the basis of the design of all residential buildings. Analogously, the C standard is the basis of the design of most of our work. The C11 standard is over 700 pages. It’s practically unreadable; is more potent than Lunesta, and seems more useful as a door stop than as an engineering document. It is one of the driest and most boring books ever to hit the street, so it's unsurprising so few of us have read it, or even flipped through the pages. But it is full of gems that the more accessible C books seem to miss. I have written about the assert() macro on occasion. In my opinion it is one of the most powerful debugging aids the language provides, yet a grep of 30 million lines of embedded code here produced not a single hit for that macro. I often talk to firmware developers who are only vaguely aware of it. Most of my C books don’t mention it. Even KR’s second edition ignores it other than a brief, 10 line mention, in a dry appendix. The C11 standard devotes a full page to assert() and show it used in examples in other locations. Appendix F is a must-read for all developers. It’s hard to get floating point math right. I see so much code where the developer painfully developed rounding and other functions, yet this appendix details functions that C provides to handle this operation. Are you familiar with isfinite()? Have you ever read a C book that talks about it? Did you know that using the comparison operators on floating point numbers may be dangerous since they don’t account for NaN? More robust comparisons are provided by the standard. Appendix C lists sequence points, whose meaning is outlined in the chapter titled “Environment,” which are a critical concept for understanding how the compiler can re-order execution. Compilers can do crazy sorts of optimizations, but sequence points bound their zaniness. The C11 standard is available here for 198 Swiss Francs, or about $210, an outrageous price for a .PDF. Various web sites make it available, at least in pre-final versions, but I have no idea about the legality of that practice. The C99 standard, more common in the embedded world, is also available. As professionals, we all owe it to ourselves, and to our careers, to have easy access to the foundational documents of our industry. And we need to read them! Only a masochist would sit down and plow through an entire standard. Instead, like enjoying a fine wine, sip at it from time to time (perhaps with a nice adult beverage at hand). Dry? Yes. But some sections are quite interesting and worthwhile. College classes on electromagnetics and circuit theory were also dry, but ours is a very technical profession and we simply must master the material. Do you have a copy of a C standard?