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;

Continue reading “A defer feature using lambda expressions”

type-safe parametric polymorphism

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

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.

Continue reading “type-safe parametric polymorphism”

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.

Improve type generic programming

This is a new paper that appeared today on the site of the C committee:
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2638.pdf

C already has a variaty of interfaces for type-generic programming, but lacks a systematic approach that provides type safety, strong ecapsulation and general usability. This paper is a summary paper for a series that provides improvements through

  • N2632. type inference for variable definitions (auto feature) and function return
  • N2633. function literals and value closures
  • N2634. type-generic lambdas (with auto parameters)
  • N2635. lvalue closures (pseudo-references for captures)

The aim is to have a complete set of features that allows to easily specify and reuse type-generic code that can equally be used by applications or by library implementors. All this by remaining faithful to C’s efficient approach of static types and automatic (stack) allocation of local variables, by avoiding superfluous indirections and object aliasing, and by forcing no changes to existing ABI.

A defer mechanism for C

An overview of a paper that presents a reference implementation of a defer mechanism (co-authored with Robert C. Seacord) has been accepted for publication at SAC’21. The full version is available as a research report on the HAL archive:

https://hal.inria.fr/hal-03090771/document

It introduces the implementation-side of a C language mechanism for error handling and deferred cleanup adapted from similar features in the Go programming language. Here is a simple example that uses such a feature:

guard {
  void * const p = malloc(25);
  if (!p) break;
  defer free(p);
  void * const q = malloc(25);
  if (!q) break;
  defer free(q);
  if (mtx_lock(&mut)==thrd_error) break;
  defer mtx_unlock(&mut);
  // all resources acquired
  // use p, q, and mut until the end of the block
  ...
}

This mechanism improves the proximity, visibility, maintainability, robustness, and security of cleanup and error handling over existing language features. The library implementation of the features described by this paper is publicly available under an Open Source License at https://gustedt.gitlabpages.inria.fr/defer/.

This feature is under consideration for inclusion in the C Standard and has already been discussed on the last WG14 meeting. The main introduction can be found in a paper written together with Alex Gilding, Tom Scogland, Robert C. Seacord, Martin Uecker, and Freek Wiedijk:

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2542.pdf

C source-to-source compiler enhancement from within

A new research report describing shnell has now appeared on HAL:

https://hal.inria.fr/hal-02998412

We show how locally replaceable code snippets can be used to easily specify and prototype compiler and language enhancements for the C language that work by local source-to-source transformation. A toolbox implements the feature and provides many directives that can be used for compile time configuration and tuning, code unrolling, compile time expression evaluation and program modularization. The tool is also easily extensible by simple filters that can be programmed with any suitable text processing framework.

A Common C/C++ Core Specification rev 2

v2 of that specification just appeared on the C comittee website:

A Common C/C++ Core Specification rev 2

For an introduction to the originial version see “A common C/C++ core specification”

Most important additions in this revision are

  • three-way comparison (spaceship operator)
  • “initializer” construct for captures of lambdas
  • a tool for textual representation of all basic types and arrays, totext
  • more attributes: core::free , core::realloc, core::noleak,
    core::writethrough, core::concurrent
  • constexpr
  • if with variable definitions

and some more cleanups and harmonizations between C and C++.

the floating point naming explosion

The recent integration of the floating point technical specifications (TS) has had a disastrous effect on the set of reserved identifiers in C. If C2x would go through as it currently stands about 1700 identifiers that were completely unprotected and unannounced would enter the global name space and nasty conflicts with user code would become unavoidable. There have been several attempts in history to introduce scoped identifiers to C, but we can’t wait for such miracles to happen before C2x is supposed to come out.

Therefore, in a paper for WG14 that will be debated in the next meeting in Ithaca, I propose to take emergency measures and rename most of these new identifiers before they hit the public. On a complementary aspect, we propose decent names for the newly introduced floating point types.

N2426 Jens Gustedt, Contain the floating point naming explosion