C/C++ Users Journal June, 2005
Lillehammer, Norway, got itself on the map by hosting the 1994 Winter Olympics. It has now settled back into being your basic small skiing village, with perhaps an overabundance of stadia and ski jumps. It's also an appealing conference venue, just a couple of hours by train north of Oslo. There's not much to do but go for invigorating walks, eat, and attend meetings.
I'm halfway through two weeks of such meetings, the twice-yearly get togethers of WG14, which manages the ISO C Standard, and WG21, which does the same for the ISO C++ Standard. Normally, I wait until the end of both to generate my regular report on what's new in the wonderful world of standards that affect CUJ readers. But deadlines being what they are, all I can talk about this month is C.
It was a busy week for WG14. No, the committee has still not begun work on a new version of the C Standard. The sentiment remains that C99 has yet to catch on widely enough in the industry. The last thing anybody wants is the prospect of yet another version looming on the horizon. It helps that Posix now requires conformance to C99. That has encouraged some companies to start shipping C99-compliant compilers, if only to get the branding needed to bid on Posix contracts. Sun and Hewlett-Packard are two notable recent additions to the C99 community.
Part of what kept us so busy was answering Defect Reports. These are official queries and/or complaints about the meaning of the current C Standard. We lump them together because an innocent question can sometimes illuminate a weakness in the C Standard that needs fixing, while a bug report can sometimes be met with an explanation instead of a change. Be assured that the kind of questions that come in these days mostly deal with pretty subtle aspects of Standard C. None of our responses are likely to change how the average C programmer interacts with the average conforming compiler. More good news is that the committee got caught up on open Defect Reports, for the first time in years.
But most of what kept us busy was a detailed review of the Technical Report on Secure C, which I first described in detail in these pages in the November 2004 issue. The first round of public comments were in, and they called for some significant changes. The most significant of all is the name of the project. "Security" is a word fraught with multiple meanings these days. Several reviewers felt it was too heavyweight a term to apply to a modest C Library designed to reduce programmer errors by making buffer-size decisions more visible. Luckily, the committee was able to agree on the more modest term "Safer C," and preserve the mnemonic meaning of the "_s" suffix on all the added function names.
Catching errors is not enough, of course. You have to do something with them. You certainly want to fail safe, not scribble all over memory. It's a good idea to return an error indicator, so that a program can know it's done something wrong if it cares to check. But a serious approach to safer C requires even more. By stages, the Safer C Library has distilled out a set of preconditions that each new function must check for, and a way of reporting failures to a user-suppliable handler. Such failures were originally given the clumsy, and somewhat oxymoronic, name "diagnosable undefined behavior." Nobody liked that, or the vague rules for specifying a handler.
The committee's response last week was to standardize the rules for registering a handler, and to characterize the precondition failures more gracefully. The original C Standard makes a clear distinction between those programming errors that must be diagnosed and those for which a diagnostic is not absolutely required. The former are violations of conditions spelled out in "Constraints" sections throughout the C Standard. The latter are forms of "undefined behavior" that can be diagnosed, given a special meaning by some implementations, or (heaven help us all) simply ignored.
What Safer C does is extend the concept of Constraints to runtime. A smart compiler might diagnose a bad call to a Safer C function and issue a compile-time diagnostic. But any implementation of the function must test that its arguments meet all preconditions. The runtime equivalent of a diagnostic is to call the diagnostic handler. If the handler returns, the function then cauterizes any output buffers and returns an error code. Only if all goes well does it dare to write into storage supplied by the calling program.
As I emphasized before, this is hardly enough to make a program absolutely secure. But it does buy a lot of safety for a small extra cost in checking. That's worth something.
P.J. Plauger
Senior Contributing Editor
pjp@plauger.com