Dealing with overflow

In the previous post we have seen that C23 will provide us with tools for efficient overflow check for arithmetic. When discussing this, several people have asked why these tools do not provide a specific model to handle overflow, such as aborting or raising a signal. The answer to this is actually quite simple:

There is no commonly agreed strategy to handle overflow.

So for the C committee (and for the gcc feature this is based upon) there was no obvious choice for a strategy. Instead, the features provide the basics to implement any such strategy based on policy decisions that will be dependent on application specific settings, be they technical or cultural

Advertisement

Checked integer arithmetic in the prospect of C23

As you might have noticed, C23 is scheduled to come out in November 2023 and will have a lot of improvements and new features, in particular for integers. One of the most controversial properties of integer arithmetic in C is the overflow behavior. C23 will have a new header <stdckdint.h> for “checked integer operations”, that helps to deal with overflow and puts the responsibility in your hands, the programmer. In addition to the result of an arithmetic operation, the interfaces provide an extra bool value that tells if the operation has been erroneous or not.

The addition that has been integrated into C23 is the core proposal and
some amendments. The history of this looks a bit confusing because later editions of the paper have removed parts that had already been adopted.

Anyhow, for many of you it is even possible to use these features in a C23 compatible way just now, because they are closely modeled after similar gcc and clang features. Since overflow still is an important source of bugs and security issues, you should just

start using checked integer operations, now!

C23 implications for C libraries

The upcoming standard C23 has a lot of additions to the C library clause. Most of them are small, some of them are big but optional. I have now finished a first version of a document that summarizes many of the changes. It has some general discussions about the following subjects

• Unicode support
• Thread safety of the C library
• Const-contract of the C library
• Changes to integer types
• Attributes

and then lists changes to individual header files of the C library.

This does not contain an detailed description of the changes to the math.h header. First, I am really not an expert on that, and second the changes there are quite invasive and we don’t have a diff-file that would clearly list them.

A defer feature using lambda expressions

In the previous post https://gustedt.wordpress.com/2020/12/14/a-defer-mechanism-for-c/ I already presented an idea for a defer feature for C, namely a feature that would provide a simple mechanism to cleanup at the end of a block, regardless how that block is left. There are many different extension out there that provide such a feature, for example POSIX’ pthread_cleanup_push and pthread_cleanup_pop, Microsoft’s __try and __finally and gcc’s cleanup attribute. Although they are used quite often, none of these extension has yet been adopted widely enough to prefer it over the others for standardization.

In a new paper

A simple defer feature for C

we present a much simpler version of a unifying framework for such cleanup features which is conditionned to the acceptance of lambdas into C23:

   defer lambda-expression;

type-safe parametric polymorphism

Among the other new proposals for C23 that WG14 received are two brilliant gems by Alex Gilding

• The constexpr specifier
• The void–which-binds: typesafe parametric polymorphism

The first is probably what you’d expect if you know the C++ feature and how it started (I think in C++11), namely a possibility to specify constants for any type (if used to declare an object) or to have simple function calls that can be forced to be evaluated at compile time. There are still some rough edges to cut (storage class, linkage) but basically, if Wg14 weren’t so predictably unpredictable, this should be a homerun.

The other one is on a whole different level, eye opening and very, very promissing. Its main idea is to add annotations to APIs to avoid breaking ABIs and code duplication at the same time.

Feature freeze for C23

The dust is now settling and we finally should have all proposals for new C23 features. Below you find links to some of the newer ones that I co-authored. Many previous proposals are still open because WG14 only voted in favor and now they have to be revisted before they can be decided.

• Only reserve names of optional functions if necessary. This mitigates the naming explosion in <math.h> and other headers. http://open-std.org/jtc1/sc22/wg14/www/docs/n2839.htm
• Avoid evaluation of sizeof for VLA expressions for which the size is already known http://open-std.org/jtc1/sc22/wg14/www/docs/n2838.htm
• Make call_once mandatory http://open-std.org/jtc1/sc22/wg14/www/docs/n2840.htm
• Identifier Syntax using Unicode Standard Annex 31 http://open-std.org/jtc1/sc22/wg14/www/docs/n2836.pdf
• Unsequenced functions v3. This adds function attributes for possible optimizations http://open-std.org/jtc1/sc22/wg14/www/docs/n2825.htm
• Pointers and integer types. In particular requires types [u]intptr_t http://open-std.org/jtc1/sc22/wg14/www/docs/n2822.htm
• Require exact-width integer type interfaces http://open-std.org/jtc1/sc22/wg14/www/docs/n2821.htm
• Function Pointer Types for Pairing Code and Data. This is indendent of the lambda proposals but should be quite usefull for them http://open-std.org/jtc1/sc22/wg14/www/docs/n2787.pdf