The week of April 3, I attended a meeting of WG14, the C standardization committee, in Markham, ON. Markham is a suburb of Toronto about 40 minutes drive north. Unlike Toronto itself, it’s not a particularly interesting destination. We had four days of rain followed by snow, freezing temperatures, and the wind, which was perfect for spending time indoors and made it easy to resist any temptation to go sightseeing.
Continue reading “Trip Report: April 2017 WG14 Meeting”
A few months ago, I had to write some internal GCC passes to perform static analysis on the GNU C Library (glibc). I figured I might as well write them as plugins since they were unlikely to see the light of day outside of my little sandbox. Being a long time GCC contributor, but having no experience writing plugins I thought it’d be a good way to eat our own dog food, and perhaps write about my experience.
Continue reading “Diagnosing Function Pointer Security Flaws with a GCC plugin”
GCC has a rich set of features designed to help detect many kinds of programming errors. Of particular interest are those that corrupt the memory of a running program and, in some cases, makes it vulnerable to security threats. Since 2006, GCC has provided a solution to detect and prevent a subset of buffer overflows in C and C++ programs. Although it is based on compiler technology, it’s best known under the name Fortify Source derived from the synonymous GNU C Library macro that controls the feature: _FORTIFY_SOURCE. GCC has changed and improved considerably since its 4.1 release in 2006, and with its ability to detect these sorts of errors. GCC 7, in particular, contains a number of enhancements that help detect several new kinds of programming errors in this area. This article provides a brief overview of these new features. For a comprehensive list of all major improvements in GCC 7, please see GCC 7 Changes document.
Continue reading “Memory Error Detection Using GCC”
Trip Report: October 2016 WG14 Meeting
In October 2016, I attended the WG14 (C language committee) meeting in Pittsburgh, Pennsylvania. The meeting was hosted by the Computer Emergency Response Team (CERT) at the Software Engineering Institute (SEI) at Carnegie Mellon University (CMU). We had 25 representatives from 18 organizations in attendance, including CERT, Cisco, IBM, INRIA, Intel, LDRA, Oracle, Perennial, Plum Hall, Siemens, and the University of Cambridge. It was a productive four days spent on two major areas:
- Work on C11 defect reports aimed at the upcoming C11 Technical Corrigendum (TC) expected to be finalized in 2017. This will be the last revision of C11 to be published. The next revision of C will be a “major” version that is for the time being referred to as C2X.
- Review of proposals for the next revision of C, C2X. To meet the TC 2017 schedule some C11 defects will have to be deferred to C2X. The C2X charter is in N2086.
Below is a list of some of the interesting C2X proposals the group discussed.
Continue reading “October 2016 ISO C Meeting Report”
Continued from Part 1.
The C and C++ standards specify that
…the default (zero) initialization for objects with static or thread-local storage duration is guaranteed to produce a valid state.
This means that, for example, defining an atomic object at file scope without an initializer as shown below is guaranteed to initialize it to a default state and default (zero) value.
Other than zero-initialization, the standards require that atomic objects with static and thread storage duration be initialized using one of the ATOMIC_VAR_INIT() and atomic_init() macros. This requirement is a vestige of the original proposal which specified atomic types as structs. The expectation was that emulated implementations that stored a mutex in the struct along with the value would define the ATOMIC_VAR_INIT() macro along the following lines
Continue reading “Toward a Better Use of C11 Atomics – Part 2”
Following the lead of C++, along with a memory model describing the requirements and semantics of multithreaded programs, the C11 standard adopted a proposal for a set of atomic types and operations into the language. This change has made it possible to write portable multi-threaded software that efficiently manipulates objects indivisibly and without data races. The atomic types are fully interoperable between the two languages so that programs can be developed that share objects of atomic types across the language boundary. This paper examines some of the trade-offs of the design, points out some of its shortcomings, and outlines solutions that simplify the use of atomic objects in both languages.
The need for software to operate on objects of basic types in an atomic way goes back to the first multiprocessor systems. Many solutions were developed over the decades, each with its own unique characteristics that made writing portable code that took advantage of those features difficult. The C11 and C++11 standards codify an approach that allows software to make use of the hardware support for atomics on the broadest spectrum of processors. The authors of the proposals for C and C++ atomics envisioned efficient, lock-free implementations of these interfaces on architectures that provide robust support for such operations. The authors, however, didn’t want to preclude lock-based emulations on older or less capable hardware. Although emulated implementations were expected to store the lock associated with each atomic object separately from the object itself, this aspect too wasn’t mandated by the proposed specification. The proposers didn’t want to preclude stateful implementations of atomics.
Continue reading “Toward a Better Use of C11 Atomics – Part 1”