DEV Community: Paul J. Lucas

A Simple Dynamic Array for C

Paul J. Lucas — Sat, 30 May 2026 01:07:55 +0000

Introduction

When many programmers get inspired to implement a dynamic array (meaning an array that grows automatically as new elements are appended) in C, they often try to incorporate the element’s type into the array. Since C lacks a template facility like C++, that often means (ab)using macros like:

#define TYPED_ARRAY(TYPE)                            \
  typedef struct TYPE##_array TYPE##_array;          \
  struct TYPE##_array {                              \
    TYPE  *elements;                                 \
    size_t len;                                      \
    size_t cap;                                      \
  };                                                 \
  static void TYPE##_array_init( TYPE##_array *a ) { \
    *a = (TYPE##_array){ 0 };                        \
  }                                                  \
  /* ... and several more functions ... */

The problems with (ab)using macros like this for typed arrays in C are:

They’re difficult to write and maintain.
The entire implementation must be in the header (leading to increased compilation times and code bloat).
Error messages involving macros are often very difficult to read.

Instead of trying to shoehorn typed arrays via macros like this into C, let’s try to implement the simplest possible dynamic array in C.

A Simple Dynamic Array

Here’s a fairly simple structure for a dynamic array:

typedef struct array array_t;
struct array {
  void   *elements;  // Pointer to array of elements.
  size_t  esize;     // Size of an element.
  size_t  len;       // Length of array.
  size_t  cap;       // Capacity of array.
};

Instead of somehow trying to incorporate element type information, we’re just going to do the simplest thing and use an element’s size in bytes and treat elements as opaque chunks of memory. We’ll leave how to interpret those bytes as a type to the user. The rest of the members should be self explanatory.

The primary functions needed are for initialization, clean-up, appending elements, and accessing elements.

Initialization & Clean-Up

Initialization is trivial:

inline void array_init( array_t *array, size_t esize ) {
  *array = (array_t){ .esize = esize };
}

The designated initializer .esize sets the element’s size; the other members are initialized to zero (or equivalent). If you wanted an array of int:

array_t int_array;
array_init( &int_array, sizeof(int) );

Clean-up, while not trivial, is still straightforward:

typedef void (*array_free_fn_t)( void *element );

void array_cleanup( array_t *array, array_free_fn_t free_fn ) {
  if ( array == NULL )
    return;
  if ( free_fn != NULL ) {
    char *element = array->elements;
    for ( size_t i = 0; i < array->len; ++i ) {
      (*free_fn)( element );
      element += array->esize;
    }
  }
  free( array->elements );
  array_init( array, array->esize );
}

A clean-up function is needed for elements that require their own clean-up, e.g., strings. The conversion to char* is needed since arithmetic can’t be done on pointers in standard C.

Accessing Elements

To access an element at a given index, we can implement:

inline void* array_at_nc( array_t const *array, size_t index ) {
  return (char*)array->elements + index * array->esize;
}

inline void* array_at( array_t const *array, size_t index ) {
  return index < array->len ? array_at_nc( array, index ) : NULL;
}

The _nc version is for “no check,” i.e., does no bounds-checking. If you’re iterating, the _nc version is fine since the index is guaranteed to be < len:

for ( size_t i = 0; i < int_array.len; ++i ) {
  int n = *(int*)array_at_nc( &int_array, i );
  // ...
}

Appending Elements

To append an element, we can implement:

inline void* array_push_back( array_t *array ) {
  array_reserve( array, 1 );
  return array_at_nc( array, array->len++ );
}

We’ll get to array_reserve shortly, but, in the mean time, notice that array_push_back does not take the element to be appended; instead, for simplicity, it merely makes room for the element and returns a pointer to the raw memory for it at which point the user can assign to it:

*(int*)array_push_back( &int_array ) = 42;

After all, the core functionality of a dynamic array is only to grow when necessary; we leave dealing with the typed elements to the user. This is similar in spirit to the standard library functions of qsort and bsearch that implement only core functionality (sorting and searching, respectively) leaving the elements to the user.

The array_reserve function is where most of the “meat” is. It reserves space for res_len additional elements. A naive implementation would grow the array by exactly res_len elements. The problem with that is if you (a) don’t know how many elements there will be in advance (which is often the case) and (b) append elements one by one, it would call realloc that, not only has to reallocate the array, but also memcpy the elements every time — which is really expensive, specifically, runs in O(n²) time.

Instead, we grow the array by at least res_len additional elements, specifically 1.5n:

#define ARRAY_CAP_MIN  4  /* Minimum array capacity. */

bool array_reserve( array_t *array, size_t res_len ) {
  assert( array != NULL );
  if ( res_len <= array->cap - array->len )
    return false;
  if ( array->cap == 0 )
    array->cap = ARRAY_CAP_MIN;
  size_t const min_cap = array->len + res_len;
  while ( array->cap < min_cap )
    array->cap += array->cap >> 1;      // grow by ~1.5x
  array->elements = realloc( array->elements, array->cap * array->esize );
  return true;
}

While this has the potential to waste memory (more in a bit), the benefit is that the expense of reallocation exponentially decreases over time and so each append is amortized to O(1).

Why 1.5 instead of 2? The problem with 2 is that doubling the size of each new allocation is always greater than the sum of all previous allocations combined, which means realloc can’t reuse even a block coalesced from previous allocations. For example, assuming previous allocations of 4, 8, and 16 (summing to 28), the next allocation will be 32, but 32 > 28, so realloc can’t reuse that block.

In contrast, growing by 1.5x yields allocations 4, 6, and 9 (summing to 19), and the next allocation will be 13, and 13 ≤ 19, so realloc can reuse that block; hence 1.5x is easier on the memory allocator by reducing fragmentation. Additionally, growing by 1.5x wastes at most 33% of allocated memory whereas 2x wastes at most 50%.

The use of ARRAY_CAP_MIN having a value of 4 eliminates the expensive initial size increases (that would start out as 2, 3, and 4).

Other Functions

The functions array_init, array_reserve, array_push_back, and array_cleanup are all you really need for a dynamic array. For convenience, you could also add functions like array_back, array_front, array_pop_back, array_qsort, and array_bsearch. Those, if wanted, are left as exercises for the reader.

Adding Type Information

Now that we’ve got a nice, small, and efficient implementation of a dynamic array, it turns out that it is possible to add type information thus making the dynamic array type-safe by using just a few small macros.

As far as I know, the following technique was invented by Daniel Hooper. The trick is to put a generic data type of interest (here, array) inside an anonymous union with a pointer to the desired element type:

#define typed_array(TYPE) \
  union { array_t array; TYPE *ptr_type; }

typed_array(int) int_array;

By using a union, ptr_type takes up no additional space. It’s also never written to nor read from: it exists only to provide type information at compile-time.

Why TYPE* and not just TYPE? Because (a) TYPE* is sufficient and (b) sizeof(TYPE*) is just the size of a pointer that’s always less than sizeof(array_t).

Given such a union, we can now implement additional wrapper macros for array:

#define typed_array_init(ARRAY) \
  array_init( &(ARRAY)->array, sizeof( *(ARRAY)->ptr_type ) )

#define typed_array_push_back(ARRAY) \
  (typeof((ARRAY)->ptr_type))array_push_back( &(ARRAY)->array )

#define typed_array_at_nc(ARRAY,INDEX) \
  (typeof((ARRAY)->ptr_type))array_at_nc( &(ARRAY)->array, (INDEX) )

Obviously, these macros require typeof from C23, but typeof has also been supported by gcc and clang as an extension to older C versions for some time.

Given those macros, we can now do:

typed_array(int) int_array;
typed_array_init( &int_array );
*typed_array_push_back( &int_array ) = 42;

that eliminates the explicit use of sizeof as well as all the casts. Optionally, you can add even more macros for pointer iteration:

#define typed_array_type(ARRAY)  typeof( *(ARRAY)->ptr_type )

#define typed_array_begin(ARRAY) (ARRAY)->array.elements

#define typed_array_end(ARRAY) \
  typed_array_at_nc( (ARRAY), (ARRAY)->array.len )

Then:

for ( typed_array_type(&ia) *e = typed_array_begin(&ia);
      e < typed_array_end(&ia); ++e ) {
  printf( "%d\n", *e );
}

Caveat

One caveat with typed_array, specifically with its use of an anonymous union, is that C doesn’t consider anonymous unions (or structures) the same type even when their members are identical:

typed_array(int) i;
typed_array(int) j;
// ...
i = j;  // error: assigning incompatible type

However, you can use typedef to make them the same type:

typedef typed_array(int) int_array;

int_array i;
int_array j;
// ...
i = j;  // OK now

Verbosity

If you think having to spell out typed_array all the time is too verbose, you could rename array to be something like vp_array (void pointer array) and then just name typed_array as array, especially if you always plan to use the typed version.

Conclusion

Personally, I find that the dynamic array implementation shown here exemplifies the less is more principle and keeps in the spirit of C. I’ve used array in my include-tidy project and it works just fine.

If you really want a type-safe version, it’s easily added on as an extra. Keeping it as an extra rather than trying to incorporate type information directly into array keeps the two layers nicely separated and makes each simpler.

My Impression of AI in Programming

Paul J. Lucas — Sun, 24 May 2026 14:47:19 +0000

Introduction

In a previous post, I wrote the following about using AI in developing my new tool include-tidy (Tidy) that uses Libclang, a library I’d never used before:

What helped a lot was using AI (strictly speaking, an LLM), specifically Google’s Gemini (because I’m too cheap to pay for Claude, especially for a personal project that I have no intention of making any money from). While I may write a follow-up blog post describing my experience, I’ll state briefly that AI saved me from having to read a lot of the documentation, read the tutorials, post questions to a mailing list or Stack Overflow, and wait for answers (if any).

This is that aforementioned follow-up blog post. If you’ve been using AI for a while, none of what follows will likely be a surprise to you. Prior to using AI for Tidy, I’d only used it for small functions or to ask corner-case questions. Using it for Tidy was my first “big” use of AI.

If this is your first encounter with my blog or me, you might be wondering “Who is this guy, and why should I care what he thinks?” I’ve been tinkering with computers for over four decades, both as a hobby and professionally. Some programmers, especially those from older generations, are pretty skeptical about AI — often referring to it as “autocorrect on steroids.” While there’s a grain of technical truth to that, it’s still pretty impressive.

Prompting

While I think the term “prompt engineering” and its related “Prompt Engineer” title are vastly over-inflated (with the latter being along the lines of “Sanitation Engineer”), you do have to be detailed and specific — just like you would be if you were submitting a question on Stack Overflow.

Unlike Stack Overflow, you won’t be chastised for asking a question that’s been asked before nor for not reading the FAQ; you won’t be questioned as to why on Earth you would want to do that; you won’t get a condescending answer or comment; you won’t not get an answer; and you’ll get an answer in several seconds.

While all that sound great, the answer you get might be completely wrong. A couple of times, Gemini said I should use an API function that doesn’t exist. After me pointing that out, it did correct itself, however.

Also, the answer you get is often only based on your exact question. It’s probably best if you think of using AI like using a monkey’s paw lest you get responses that technically satisfy your request, but with unintended consequences.

For an example, here’s my very first prompt to Gemini to create Tidy:

Write a program using clang's API that, given either a C or C++ source file, prints every symbol (macro, constant, function, type, variable, etc.) and the file and line number where that symbol was declared, or "unknown" if it can not be determined.

And it printed out a few screens’ worth of C code showing what file from Libclang to #include, what functions to call to initialize and clean-up Libclang, how to parse a source file and iterate over its abstract syntax tree (AST). Sure, I could have ready Libclang’s tutorial, but Gemini’s response was tailored to what I wanted to do.

Of course the program it generated was nowhere near complete. It didn’t handle command-line options, configuration files, errors, colored output, or all the corner cases when analyzing C or C++ source files. These things would be fleshed out in the coming weeks. But I was off to a good start.

Mundane Tasks

One other nice thing about using AI is that you can have it do mundane code that you could do, but don’t want to be bothered because the code is boring. For example, Tidy needs to pre-scan command-line arguments looking for those preceded by -Xtidy to split them into two arrays: those that are Tidy-specific and those that should be passed along as-is to Libclang. Here was my prompt:

Given argc and argv for main in a C program, there are two types of options: (1) An -Xtidy option, that is an option with -Xtidy preceding it; and (2) Just an option. "Option" is either a short option or a long option.

I want to manipulate argc and argv such that all options that are preceded by -Xtidy are split off into a separate tidy_argv array along with tidy_argc leaving argv stripped of all -Xtidy and the immediately following option.

And it just did it correctly in several seconds, all without me having to debug the inevitable off-by-one errors had I written the code.

Experience

If you’re an experienced programmer, you’re able to look at the generated code and quickly tell whether it looks right. So for an experienced programmer, AI is quite the accelerant; if you’re an inexperienced programmer (or not even a programmer), then I suppose you’re at the mercy of the monkey’s paw.

Finding Bugs

Another thing you can do, when you’re finished with a particular .c or .cpp file, is upload it and ask, “Can you find any bugs in this code?” And it does. Of course you can’t tell whether it found all bugs, so you should still write unit and other tests.

It can of course report false positives as it did with my c_chan project. It thought my use of a particular mutex was wrong. Granted, it was an atypical way to use a mutex that perhaps would have also confused human programmers. But it also did find a few other real bugs including uninitialized structure members and noticing that the tv_nsec member of a timespec structure needs to be in the range 0–999999999, so I should add code to check for overflow.

What the AI Did Not Do

Like many codebases, the bulk of the code isn’t directly involved in doing whatever the main point of the codebase is. In Tidy’s case:

Only 18% has to do with scanning for #include directives and mapping symbols to include files.
26% is just “utility” code (small functions that make writing the rest of the code easier).
25% is just for parsing configuration files (syntactically parsing TOML, semantically interpreting it, checking for errors, printing error messages with exact line and column).
15% for generic data structures (dynamic arrays, red-black trees).
9% for command-line parsing.
8% for test.

I used AI to assist with (not write) code using Libclang, not for utility code nor configuration files, only a tiny bit with the command-line (to split arguments), and not for test.

Implications

While my intent for this blog post is only to describe my impressions of AI for software development for me, I’m probably going to get asked in the comments what I think the implications are for software development as a whole, so I might as well just address that now.

While there certainly has been and will continue to be a lot of hype about AI, as I’ve said, it’s helped me a lot with Tidy. It’s a game-changer for software development. In the hands of an experienced programmer, it’s an accelerant. Since I’m no longer an inexperienced programmer, I can’t directly comment on what AI use is like for inexperienced programmers. It’s very likely also an accelerant, but inexperienced (or non-) programmers can’t spot wrong or security-omitting code when they see it. There will be more data breaches and lawsuits for sure.

You’ve undoubtedly heard (and perhaps unfortunately directly experienced) the rampant layoffs at tech. companies. As I commented, yes, there have been lots of layoffs, but I think AI is being used as a scapegoat to make CEOs not sound incompetent and companies not sound in trouble. The reasons for layoffs are the same as ever:

The company stupidly over-hired in general.
A new product or service didn’t pan out.
The company is in financial trouble.

All of which make the CEO look incompetent. Instead by blaming AI, it makes the CEO look savvy by simultaneously adopting cutting edge technology while also cutting expenses — both of which are rewarded by Wall Street.

To that, I’d also add the following reason for layoffs. Incompetent CEOs:

Might actually believe all the hype and think they can replace developers by AI.

Consider the following scenario. You’re the CEO of a tech. company that sells a flagship software product with a large customer base. You have 100 developers on staff. On average, you add one new feature and fix 10 bugs per month. You’d like to add more features and fix more bugs per month, but can’t afford to hire more developers. Now along comes AI and you have two options:

Continue to add one new feature and fix 10 bugs per month, but with fewer developers and expense.
Add two or even three new features and fix 30 bugs per month with the same number of developers using AI as an accelerant.

What sane CEO chooses option 1 thinking, “We’re happy with our current pace of development as are our customers”? Option 2 makes both existing customers happier and likely will be better at attracting new customers. Indeed, there has been some research that supports this.

So if you’ve been affected by a layoff, perhaps you can take some comfort (schadenfreude) in the likelihood that the CEO is incompetent.

Conclusion

AI is very likely here to stay. It’s clearly a developer accelerant. Sure, there will be shake-ups, buy-outs, and a few bankruptcies, because, at least currently, running AI hemorrhages money. Making AI profitable is another matter. Big players like Google that have an alternate cash cow (advertising) can fund AI indefinitely; Anthropic is only just now turning a profit for the first time ever. It’s unclear whether they’ll be able to continue to turn a profit. The next few years will tell.

Symbolic Constant Conundrum

Paul J. Lucas — Sat, 23 May 2026 00:34:36 +0000

Introduction

A symbolic constant in any programming language is a name — a symbol — that can be used to stand in for a constant — a literal value. Programming languages inherited symbolic constants from mathematics that has many of them grouped by specific field of study. Examples include: π (pi), c (speed of light), e (Euler’s number), G (gravitational constant), h (Plank’s constant), etc. While those exact constants can be defined and used in programs, many programs define program-specific constants. Using constants is better than using magic numbers.

Both C and C++ have acquired multiple ways to specify symbolic constants as their respective languages have evolved over the decades, namely:

Macros (via #define).
Enumerations.
const.
constexpr.

Knowing which of the ways to use in a particular case can be quite the conundrum.

Macros

Originally, C only had macros, specifically, object-like macros, e.g.:

#define BUF_SIZE  8192

Macros are adequate, but not good. Why? Macros in general ignore scope, so you typically have to give macros very specific (long) names to avoid collision.

Enumerations

Enumerations in C and C++ are better, especially for declaring a set of related constants. In C++ with enum class, they can even be scoped to avoid collisions; in C, however, they’s still in the global scope.

The other caveat is that they can be constants only for integral values.

`const`

As I described for C and C++, you can use const for constants, e.g.:

static unsigned const BUF_SIZE = 8192;

char BUF[ BUF_SIZE ];

int main() {
  char local_buf[ BUF_SIZE ];
  // ...
}

In C++, that will compile just fine without warning; in C, it’ll either be accepted with warnings or rejected entirely, especially if you disable language extensions. Why? Because const is a misnomer since it really means immutable, not constant, and C is more picky about it.

While the declaration of BUF might be accepted, the declaration of local_buf will either be considered a variable length array (VLA) (that, as I pointed out, you should probably never use), or rejected since VLAs are an optional feature and not all compilers support them (notably, Microsoft’s C compiler doesn’t).

A common work-around in C (prior to C23, see below) is to (ab)use enum:

enum {
  BUF_SIZE = 8192
};

That is, use a nameless enumeration. The advantage is that enumeration constants really are constant.

`constexpr`

If you’re using C++11 or later, or C23 or later, there’s constexpr. Unlike const, constexpr really means constant. This is by far the best option for declaring constants:

constexpr unsigned BUF_SIZE = 8192;

Conclusion

To summarize:

If you’re declaring a set of related, integral constants, use enum (in C) or enum class (in C++).
Otherwise, use constexpr if you can.
Otherwise, use const.
Otherwise, use #define as a last resort.

include-tidy: A Tool to Enforce Include-What-You-Use

Paul J. Lucas — Fri, 22 May 2026 01:56:57 +0000

Introduction

Unlike Go where the language definition itself via its compiler strictly enforces the inclusion of modules (i.e., include exactly what you use, no more, no less), neither the C nor C++ language definitions have an equivalent enforcement. This can lead to two problems:

If you unnecessarily include a header that’s not needed (i.e., no symbols from it are referenced), then compilation gets a tiny bit slower. For small codebases, this is negligible; for larger codebases where build times can take the better part of an hour or even exceed an hour, it matters.
If you don’t directly include a header that’s needed (i.e., one or more symbols from it are referenced), then if you remove a seemingly unrelated #include, the build can break. Alternatively, your program may build just fine on one platform, but fail on another due to either system headers being slightly different or #ifdefs.

To avoid both problems, you should follow the include-what-you-use principle, namely that a source file:

Directly includes every header file exactly once from which it references symbols.
Does not include a header file from which it does not reference symbols.

While you can attempt to adhere to that principle manually, it can be difficult as the number of headers either in or used by a project increases.

You’d think there would be a way to automate checking a source file for violations of the principle — and there is. After just a little bit of searching, I found include-what-you-use.

`include-what-you-use`

Having found include-what-you-use (iwyu), I tried it out. It sort-of worked, but gave incorrect suggestions. For example, when using getopt_long via Gnulib, it said I needed to include getopt-ext.h. While that’s technically correct (because that’s the file in Gnulib that declares getopt_long), that file is a Gnulib implementation detail that user’s aren’t supposed to know or care about; users are still only supposed to include getopt.h. Iwyu has a way to fix this via “mapping files,” but it’s annoying that you have to do it manually.

It seemed to me that if you include a standard(ish) header like getopt.h, then any headers that getopt.h includes should be considered implementation details, i.e., getopt.h should automatically be a proxy for headers it includes so that any symbols declared in those other headers should be treated as-if they were declared in getopt.h.

Since the sets of C, C++, and POSIX standard headers are defined, then any header included by one of the standard headers should automatically be considered an implementation detail and the standard headers should automatically proxy for those other headers.

Aside from that, I found iwyu less than ideal in a few other ways:

Some configuration is done via the aforementioned mapping files while other configuration is done via special IWYU comments in source code.
Iwyu has been around since 2011. As of this writing in 2026, that’s 15 years (!) and it’s still only at version 0.26. While it is under active development, it’s apparently progressing very slowly.
Looking at its source code repository confirms development is progressing slowly.
Looking at its open issues, it’s probably going to be a while since those get fixed.
Part of the slowness might be due to iwyu using the C++ LLVM API that’s not intended to be a stable API. (It’s intended to support LLVM and clang themselves.) Hence, any time the API changes, they authors have to spend time updating iwyu.
When a file has no violations (adheres to the include-what-you-use principle), there’s no way to have iwyu be silent.
It uses underscores for its long command-line options that are more annoying to type than dashes.

`include-tidy`

Introduction

Given the state of iwyu, I decided to write my own tool to enforce the include-what-you-use principle: include-tidy (Tidy). I optimistically (naively?) thought “How hard can it be?” While the core functionality wasn’t hard (I implemented it in a couple of weeks), it’s invariably the corner cases, the last 10%, that takes 90% of the time. Even so, I’ve gotten Tidy to 1.0 in approximately two months.

While it’s non-trivial to write a full C parser since C is (still) a relatively small language, is tractable for one person; but it’s simply too much work to write a full C++ parser. Instead of using the unstable Clang C++ API, I used the stable Libclang C API instead to do all the parsing.

Use of AI

What helped a lot was using AI (strictly speaking, an LLM), specifically Google’s Gemini (because I’m too cheap to pay for Claude, especially for a personal project that I have no intention of making any money from). I’ll state briefly that AI saved me from having to read a lot of the documentation, read the tutorials, post questions to a mailing list or Stack Overflow, and wait for answers (if any). My full impression of AI is a story for another time.

My use of AI does not mean include-tidy was written by AI, certainly not copied verbatim (I don’t like its coding style); but the AI certainly pointed me in the right direction.

Configuration

Unlike iwyu, I wanted Tidy to be fully configurable via files. The choices these days are JSON, TOML, XML, and YAML. IMHO, the least bad of these is TOML. Given that choice, the next task was to be able to parse TOML files.

I looked for a TOML library with a C API and found a couple, but it wasn’t obvious which one was better. I also didn’t like the idea of having another dependency in addition to Libclang. So I decided to implement my own TOML libary. I optimistically (naively?) thought “How hard can it be?” (Sound familiar?)

Actually, compared to implementing Tidy, implementing a TOML library was much easier. Part of that was due to me not having to implement a full TOML parser because Tidy simply doesn’t need things like dates, times, floating-point numbers, arrays of or inline tables, multi-line strings, or Unicode.

Tidy also implements configuration file “layering.” There can be a default, system-wide configuration file in /etc/xdg/include-tidy/config.toml (Tidy implements the XDG Base Directory Specification.), a user-specific configuration file in ~/.config/include-tidy/config.toml, and a project-specific configuration file in the project’s source directory. “Layering” means that settings given in more local configuration files override the same settings in more system-wide configuration files.

Command-Line Parsing

One thing I like about iwyu is that it can be used as a drop-in replacement for either a C or C++ compiler, such as either clang or gcc, in that iwyu accepts all command-line options that the compiler accepts, in particular all -D (macro define) and -I (include path) options. This ensures that the code that iwyu “sees” is exactly the same as the compiler normally sees.

A problem with that is how do you specify iwyu-specific command-line options to iwyu itself? The solution iwyu used is that all such options are preceded by -Xiwyu. I decided to do the same for Tidy except use -Xtidy.

Normally, I’d just use getopt_long() as described here to parse command-line options; but implementing -Xtidy requires that the options be split into Tidy-specific options (with every occurrence of -Xtidy removed) and everything else to be passed as-is to Libclang.

Include Paths

Every C or C++ compiler knows what its default set of include directories are; Libclang needs to be told. The best thing to do is simply to ask clang via:

clang -E -v -xc - </dev/null 2>&1

where -E means run only the preprocessor state, -v requests verbose output, -xc sets the language to C, - reads from stdin, in this case from /dev/null. Among other things, clang fortuitously prints output like (on macOS):

#include <...> search starts here:
 /usr/local/include
 /opt/local/libexec/llvm-22/lib/clang/22/include
 /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include
End of search list.

clang can be called with that exact command via popen() and its output can be parsed looking for the #include <...> search starts here: and End of search list. These directories can then be added as arguments to -isystem command-line options.

More Command-Line Parsing

To complicate matters, the command-line arguments have to be pre-scanned to look for:

The last argument to get its filename extension to know what language, and thus which include directories, we need.
An -x option that specifies the language overriding the filename extension.
A --clang or -C option to allow the user to override the path to clang.

All this before ever calling getopt_long().

Sample `include-tidy.toml` Configuration File

Not surprisingly, I now eat my own dog food and use include-tidy to tidy itself and my other projects. Here’s include-tidy’s configuration file:

[config.h]
ignore-as-argument = true

[pjl_config.h]
first = true
keep = true
proxy = [
    "attribute.h",
    "config.h",
]

The config.h file is auto-generated by Autotools. Auto-generated files should not be run through Tidy since you’re not responsible for their contents. That’s what the ignore-as-argument says and this still allows you to run Tidy easily for each file in *.h without having to make a special case to exclude it.

For my projects, I create a pjl_config.h file that wraps config.h, adds its own macros, and also include attribute.h. This should always be the first file included (hence the first = true), should always be included because it affects other files included from Gnulib (hence the keep = true), and is a proxy for the other two, i.e., if pjl_config.h is included, then it’s as if attribute.h and config.h were included also.

Data Structures

The main data structure is one for an included file:

enum tidy_sort_rank {
  TIDY_SORT_FIRST       = -2, // The very first `#include`.
  TIDY_SORT_ASSOCIATED  = -1, // After first, but before default.
  TIDY_SORT_DEFAULT     =  0  // Default sort rank.
};

typedef struct  tidy_include    tidy_include;
typedef enum    tidy_sort_rank  tidy_sort_rank;

struct tidy_include {
  CXFile         file;              // File included.
  CXFileUniqueID file_id;           // Unique file ID.
  char const    *abs_path;          // Absolute path.
  char const    *rel_path;          // Relative path.
  tidy_include  *includer;          // Include including this.
  tidy_include  *proxy;             // Proxy include, if any.
  unsigned       depth;             // Include depth.
  array_t        lines;             // Line(s) included from.
  tidy_sort_rank sort_rank;         // Sorting rank.
  bool           elide;             // Elide if necessary?
  bool           keep;              // Keep if unnecessary?
  bool           is_local;          // Local include file?
  bool           is_proxy_explicit; // Was proxy explicit?
  rb_tree_t      symbol_set;        // Symbols referenced.
};

rb_tree_t tidy_include_set;

where:

Anything with a CX prefix is from Libclang. CXFile is just an opaque handle to a file; CXFileUniqueID is an ID Libclang uses for unique file identification. I use it as the key for tidy_include_set (that uses rb_tree, an implementation of a Red-Black tree).
lines is an array of line numbers that the file was included from. If the length > 1, it means the file was erroneously included more than once and Tidy reports this.
Normally when printing all include files (when requested), Tidy follows proper header file etiquette and puts all local includes first, non-standard, non-local files (such as from a third-party library) second, and standard includes last; within each group, files are sorted alphabetically. The tidy_sort_rank allows files (like pjl_config.h) to be put first followed by a .c file’s associated .h file.
symbol_set is the set of symbols referenced from that include file. Tidy will print as many of those as will fit in a comment following the #include (unless told not to).

The rest of the fields should be relatively self-explanatory.

The other main data structure is one for a referenced symbol:

typedef struct tidy_symbol tidy_symbol;

struct tidy_symbol {
  char const *name;                 // Symbol name.
};

static rb_tree_t symbol_set;        // Set of symbols.

Since the structure has only one member, it could be eliminated; but I kept it for future-proofing in case I ever want or need to add additional members.

Algorithm Part 1: Included Files

The first part of the algorithm is to iterate through the abstract syntax tree (AST) of the translation unit (TU) looking for #include directives. Libclang provides a clang_visitChildren() function that you pass a visitor function to.

The visitor function gets the file being included (the “included”), the file including it (the “includer”), creates a new tidy_include object if the included hasn’t been seen before, an initializes depth that, if zero, means the file was directly included, and initializes other members.

If the included file has been seen before, it’s possible that it was indirectly included before, but is directly included now. If that’s the case, then reset the included’s depth to zero and includer to NULL.

For this part, there’s one other special case. Consider:

</usr/include/sys/wait.h>
  </usr/include/sys/signal.h>   // #define SIGSTOP 17
...
</usr/include/signal.h>
  </usr/include/sys/signal.h>

That is, a standard header (e.g., sys/wait.h) includes a non-standard header (e.g., sys/signal.h) so sys/signal.h’s includer is set to sys/wait.h.

Later, the standard header version of the non-standard header (e.g., signal.h) is included that also includes the non-standard header (sys/signal.h), so sys/signal.h’s includer should be reset to be signal.h because, later still, sys/signal’s proxy will then be set to be signal.h, not sys/wait.h, so signal.h will be considered the header that defines SIGSTOP (which is correct) instead of sys/wait.h (which is incorrect).

Algorithm Part 2: Include File Proxies

A second pass of all #include directives is needed to initialize implicit proxies. An include file p can be a proxy for an included file i only if:

Both i and p are non-local includes, i.e., #include <...>.
i is not a standard header.
i is not directly included (depth > zero).

There’s an exception at least when using Gnulib. Consider:

<../lib/stdlib.h>
  </usr/include/stdlib.h>

That is, a local implementation of a standard header (as is done when using Gnulib) eventually does a (non-standard) #include_next to include the real standard one. The local header (even though has a standard name) should be a proxy for the real one.

Algorithm Part 3: Symbols Referenced

Now that all the include files have been found and proxied, a third pass through the AST is needed, this time looking at every symbol (identifier), figuring out where it’s declared, and checking whether the header file that does so is directly included. This turned out to be harder than I expected. A lot harder. Part of it is due to my naivete (“How hard can it be?”), part is due to quirks of C, and part is due to limitations and quirks of Libclang.

Complete vs. Incomplete Types

Consider the following declarations (borrowed by my cdecl project):

// c_type.h
struct c_type {
  // ...
};

// types.h
typedef struct c_type c_type_t;

// c_ast.h
struct c_ast {
  c_type_t type;
  // ...
};

// dump.h
void c_type_dump( c_type_t const *type, FILE *fout );

Suppose we’re tidying c_ast.h. Which header(s) does it need to include? Clearly, it needs types.h because it declares the typedef for c_type_t. But c_type.h is also needed because the complete type for the c_type_t — struct c_type — is needed for the member declaration.

In contrast, now suppose we’re tidying dump.h. Which header(s) does it need to include? Only types.h because c_type_t is used only as part of a pointer declaration and C allows incomplete types to be used just fine in such cases. (C++ is the same, but also allows incomplete types for reference declarations.)

Macros

Preprocessor macros add a whole other dimension of complication. Consider the declaration:

// util.h
#define POINTER_CAST(T,EXPR)    ((T)(uintptr_t)(EXPR))

Because the macro references uintptr_t, util.h should include stdint.h so the user of the macro can treat it like a black box.

In Libclang, macro definitions don’t form part of the AST. Instead, when a definition is encountered, you have to get all the tokens comprising it and iterate over them. But first you have to parse function-like macros’ parameters, create a set of them, and exclude them from the tokens while iterating. You also have to exclude __VA_ARGS__ and __VA_OPT__.

The Preprocessor’s `##` Operator

Another limitation of Libclang is that symbols formed via the preprocessor’s ## (paste) operator aren’t “seen” by Libclang. Consequently, if such a symbol is declared in a header is referenced and no other symbols from that header are referenced, Tidy won't think the header is necessary. For example:

#include <readline/readline.h>

#define RL_PROMPT_IGNORE(SBUF, WHEN) \
   strbuf_putc( (SBUF), RL_PROMPT_ ## WHEN ## _IGNORE )

void prompt_create( strbuf_t *sbuf ) {
  RL_PROMPT_IGNORE( sbuf, START );
  // ...

The expansion of RL_PROMPT_IGNORE will create RL_PROMPT_START_IGNORE that’s declared in readline.h. If no other symbols from it are referenced, Tidy will incorrectly think the header is unnecessary.

As an alternative to not using ## here, you can add dummy code seen only by Tidy (and Libclang):

#ifdef __include_tidy__
void explicitly_reference_symbols() {
  (void)RL_PROMPT_START_IGNORE;
}
#endif

That is, Tidy implicitly defines __include_tidy__ when tidying. By explicitly referencing such a symbol directly via dummy code, Libclang will “see” it and Tidy will correctly think the header is necessary. Because such code is never compiled, the code can be anything (but it still has to be legal and should not generate warnings).

Conclusion

Tidy was an interesting (and sometimes frustrating) project to work on. I’m sure there are still bugs, likely more-so with C++ code since most of my testing was with C code.

A Fix for Time Machine Always Making Full Backups

Paul J. Lucas — Mon, 23 Feb 2026 13:50:14 +0000

Introduction

At some point, I upgraded the macOS version on my iMac from Sequoia to Tahoe. I think this was the trigger that starting making Time Machine always perform full backups to my Mac Mini server. (Normally, it’s supposed to perform incremental backups.) Not only was this a lot slower, but it filled up my back-up disk and caused “disk full” errors. I Google’d, I asked LLMs, tried several things — nothing fixed it. I had to disable Time Machine backups until I found a solution.

The Fix

I eventually stumbled across this answer. I’ve distilled the fix into a script:

#! /usr/bin/env bash

set -e # stop on error

ATTRIBUTES=(
  com.apple.backupd.BackupMachineAddress
  com.apple.backupd.ComputerName
  com.apple.backupd.HostUUID
  com.apple.backupd.ModelID
  com.apple.timemachine.private.structure.metadata
)

DIR=/System/Volumes/Data

for attr in "${ATTRIBUTES[@]}"
do xattr -d $attr $DIR
done

At this point, I figured I might as well try it. So I:

Removed the remote disk as a backup destination.
Deleted the old backup.
Ran the script locally on the iMac.
Re-added the remote disk as a backup destination.
Kicked off a new backup.

It took several hours to do the first full backup, but after that, it started doing only incremental backups again. Huzzah!

The reason for this article is to help spread this fix around the Internet to make it easier to stumble across for someone else having the same issue.

Note that neither I nor very likely the original author of the fix can say that this fix will fix all situations that might cause Time Machine always to do full backups.

Musings on Structure Declarations

Paul J. Lucas — Sat, 21 Feb 2026 15:34:59 +0000

Introduction

This article is sort-of a follow-up to my Musings on C & C++ Declarations and Why C Requires the “struct” Keyword for Structures articles specifically focusing on structure (struct) declarations. As a preview, all of the following are valid uses of struct (independently, but not necessarily consecutively in the same program):

struct point;                                // 1
struct point { int x, y; };                  // 2a
struct point { int x, y; } p;                // 2b
struct { int x, y; } p;                      // 3
typedef struct { int x, y; } point;          // 4
typedef struct point { int x, y; } point;    // 5a
typedef struct point_s { int x, y; } point;  // 5b
typedef struct point { int x, y; } point_t;  // 5c

1. Forward Structure Declaration

A declaration like:

struct point;  // Forward declaration.

is a forward declaration that effectively tells the compiler “point is a structure” but without any other details. What use is that? It allows you to:

Create an opaque type.
Break bidirectional type dependencies.

An opaque type can be used as part of an API for a library where you want to keep the details of a structure hidden from the user. This has two benefits:

It prevents the user from messing around with the members of the structure when they shouldn’t.
It makes upgrading a library much simpler.

Consequently, users are forced to use only your API to create, manipulate, and destroy objects of such a type. It allows you as the library maintainer to add, remove, or change its members at will without fear of breaking users’ programs. It also allows users to upgrade the version of your library that they use as a drop-in replacement of the shared object file (.so) without having to recompile their programs. This is often very useful in live, production systems.

However, opaque types aren’t without caveats:

All objects must be dynamically allocated. This is both slower and more taxing on the memory allocator, especially for many small objects. (However, you might be able to use an arena.)
No functions operating on an object of the type can be inline that may yield worse performance.

A forward declaration can also be used to break interdependencies. For example, in cdecl, an AST node for a declaration can have an optional alignment; that alignment can be given by a another AST node:

struct c_alignas {
  // ...
  union {
    // ...
    struct c_ast *type_ast; // Forward declaration.
  };
};

struct c_ast {
  c_alignas align;          // Alignment, if any.
  // ...
};

Unlike C++, a stand-alone forward declaration for a structure isn’t actually needed most of the time since the mere act of mentioning a struct type implicitly creates a forward declaration for it. Above, inside c_alignas, the struct declaration simultaneously:

Forward-declares c_ast as a structure; and:
Also declares type_ast to be a pointer to such a structure.

2. Ordinary Structure Declaration

A declaration like:

struct point { 
  int x, y;
};

is just an ordinary structure declaration; a declaration like:

struct point {
  int x, y;
} p;           // Simultaneously declare 'p' as point.

simultaneously:

Declares an ordinary structure; and:
A variable of that structure.

Personally, I don’t like doing this since it’s easy to miss the declaration of the variable way down at the bottom. For readability, I’d rather be a bit redundant by using separate declarations:

struct point {
  int x, y;
};

struct point p;  // Separate declaration is clearer.

3. Unnamed Structure Declaration

Perhaps curiously, struct can be used without a tag name:

struct { int x, y; } p;

That declares an unnamed structure that’s effectively a one-off. Note that an unnamed structure is not the same as an anonymous structure.

Although unnamed structures by themselves are allowed by the grammar, the only use I can think of for them is declaring multiple variables in a for loop initialization clause. Additionally, two identical unnamed structures are considered different types:

struct { int x, y; } q;
q = p;                   // Error: different types.

4. `typedef` Unnamed Structure Declaration

The only place an unnamed structure is useful is when it’s in combination with a typedef:

typedef struct {
  int x, y;
} point;

Such declarations are common in C code because they bypass the odd tags namespace and directly make structures be first class citizen types.

Personally, I don’t like doing this since it hides the name of the structure way down at the bottom just like the variable in #2 above. As above, I’d rather be a bit redundant by using separate declarations:

typedef struct slist slist;
struct slist {
  slist *next;
  void  *data;
};

You can put the typedef first since, as stated in #1 above, the mere act of mentioning a struct type implicitly creates a forward declaration for it.

The advantage of putting the typedef first is that you can then use it in the definition of the structure itself as is common in self-referential structures like the singly linked list shown above.

5. `typedef` Structure Declaration

The last three declarations:

typedef struct point { int x, y; } point;    // 5a
typedef struct point_s { int x, y; } point;  // 5b
typedef struct point { int x, y; } point_t;  // 5c

combine typedef with that of a named structure into the same declaration:

Case (a) just uses the same name for the tag as the type.
Case (b) appends _s to the tag (“s” for struct). (I’ve seen some codebases do this.)
Case (c) appends _t to the type. (I’ve seen other codebases do this — even though you really shouldn’t since the _t suffix is reserved for use by POSIX.)

Consistent with case #4 above, I personally don’t like doing any of these either for the same reason. Again, I’d prefer separate declarations.

Unions & Enumerations

Everything written above also applies to both unions and enumerations with the exception that enumerations can’t be forward declared (until C23 and with fixed-type enumerations).

C++

As mentioned previously, C++ effectively does an implicit typedef for every structure declaration. To keep compatibility, C++ allows all the ways in which a structure can be declared and referred to in C also:

struct point { int x, y; };

point p1;         // Ordinary C++ declaration.
struct point p2;  // C declaration for compatibility.

Conclusion

Due to the quirky tags namespace, there are several ways to declare structures that has led to inconsistencies across codebases. For your own code, pick one style and use it consistently.

Why C Requires the “struct” Keyword for Structures

Paul J. Lucas — Fri, 20 Feb 2026 02:16:00 +0000

Introduction

Regardless of whether you’ve been programming in C for many years or have only recently started, you might wonder why structure declarations require that the struct keyword be included. For example:

struct point {
  int x, y;
};

point p1;         // Error: "struct" required.
struct point p2;  // OK.

Obviously, struct is needed to declare a structure, but that’s not what this article is about. This article is about why, once declared, struct is still needed to use the previously declared structure type. If you omit struct, the compiler still knows what you mean, but it pedantically requires that you include the struct keyword anyway.

If you’ve programmed in other languages, this requirement seems even more curious because no other language that allows you to declare “structure” (Go), “record” (Pascal), or “class” (C++, Java, Python, and many others) types requires repeating a keyword when you use the type. In other languages, such a type becomes a “first class citizen” that can be used just the same as a built-in type like int.

Indeed, when Stroustrup designed C++, he made it so that structure (and class) names are useable as-is without needing to be prefixed by a keyword. He gave his rationale in The Annotated C++ Reference Manual (§3.1c, p.26) an excerpt of which is:

Requiring that such prefixing always appear would compromise the effort to make use of user defined types, such as complex, as similar as possible to use of built-in types, such as int.

Formally, structure, union, and enumeration names are in a separate “tags” namespace. (I’ll get to unions and enumerations later, but let’s stick to structures for now.) This means you can have both a structure name and some other identifier name (variable or function) with the same name. For example, POSIX defines stat as both a structure and a function:

int stat( char const *path, struct stat *buf );

One not-very-helpful reason why the compiler requires struct is because that’s how Ritchie designed C. But then the question becomes, “Why did Ritchie design C that way?”

So as not to keep you in suspense, as far as I’ve been able to tell, nobody definitively knows the answer. Sadly, we lost Ritchie in 2011, so nobody can ask him. However, some people have offered plausible explanations for why struct is the way it is.

Origin Story

Where did the struct keyword come from? It’s most likely from Algol 68 that has both STRUCT and UNION as keywords.

Note that the Algol family of languages uses stropping for keywords, so bold, or some other mechanism, is required to represent keywords.

But even in Algol 68, there’s no tags namespace. That idea seems unique to C.

C Archeology

If you do some digging, you might come across Ritchie’s C Reference Manual (CRM) published in 1974 that predates The C Programming Language (TCPL1) first published in 1978 by four years. In CRM §8.2 Type specifiers, it says:

type-specifier:
        int
        char
        float
        double
        struct { type-decl-list }
        struct identifier { type-decl-list }
        struct identifier

Two things to note:

If you scan the entire CRM, nowhere is typedef mentioned. That’s because early versions of C didn’t have typedef.
This means that all types start with a keyword that would make writing any compiler simpler.

The lack of typedef can be independently verified by scanning the source code for the C compiler, specifically its keyword table, that’s part of Sixth Edition Unix (Unix V6) released in 1975 — no typedef.

Implications

As for making it simpler to write a compiler, consider the following:

A * B;          // What is this?

Without typedef, A and B must be variables, so the above is an expression for A times B. However, once you add typedef, A could be a type:

typedef int A;  // "A" is a synonym for "int"

If it is a type, then the above declares B to be a pointer to type A. Hence, it’s context-sensitive. This definitely complicates both the parser and the lexer often requiring a lexer hack.

Hence, it’s likely that Ritchie required struct to make writing the compiler simpler. He may have also believed it made code easier to read for humans. (Generally, programming languages that are easier to parse are also easier for humans to understand.)

`typedef`

By the time TCPL1 is published in 1978, typedef was added to C. This too can be independently verified by scanning the source code for the C compiler, specifically its keyword table, that’s part of Seventh Edition Unix (Unix V7) released in 1979 — with typedef.

typedef is quite handy, both for hiding implementation details especially for types that vary across platforms and helping to write complicated declarations that C is infamous for. Consider:

void (*signal(int sig, void (*func)(int)))(int);

which is the declaration for the POSIX library function. According to cdecl (line breaks added for readability):

cdecl> explain void (*signal(int sig, void (*func)(int)))(int)
declare signal as function
        ( sig as int,
          func as pointer to function (int) returning void )
    returning pointer to function (int) returning void

That can become much simpler by using typedef:

typedef void (*sig_t)(int);
sig_t signal( int sig, sig_t func );

Hence, Ritchie added typedef despite making the compiler harder to write.

Once typedef was added, then Ritchie could have retroactively altered the way struct is handled by doing away with the tags namespace and making structure types first class citizens. But by this time, there was already a lot of C code out there and such a change would have broken many programs. For better or worse, the way struct worked was metaphorically carved into stone by now.

If it’s any consolation, typedef can be used to make structure types into first class citizens:

typedef struct point point;
point p3;         // No "struct" needed now.

That is, typedef makes point in the global namespace be an alias for point in the tags namespace. The fact that they have the same name is fine since they’re in different namespaces. Personally, I do this for my own C code. However, other people have different views on when typedef should be used.

Unions & Enumerations

If you look back at the type-specifier from CRM, you might also notice that neither union nor enum are there either. Unions became part of C by the time of Unix V7 and TCPL1, but enumerations didn’t become part of C until C89.

Regardless, both union and enum work similarly to struct in that their names are in the same tags namespace. Ritchie very likely did this for consistency.

Conclusion

So the most likely answer as to why C requires struct is that it originally made all types start with a keyword that in turn made writing the early compiler simpler.

Using Arenas for Easier Object Management

Paul J. Lucas — Thu, 19 Feb 2026 02:47:54 +0000

Introduction

When I started updating Cdecl, one of the first things I did was, as I then described, to use an abstract syntax tree (AST) data structure to represent a declaration. During construction of the AST, placeholder nodes sometimes need to be created until the final type is able to be determined. For example, consider the declaration:

int a[2][3];

When parsing, upon encountering the first [, we know it’s an array 2 of “something” of int, but we don’t yet know either what the “something” is or whether it will turn out to be nothing. It’s not until the second [ that we know it’s an array 2 of array 3 of int. (Had the [3] not been there, then it would have been just array 2 of int.) Once the final type is known, the placeholder node can be replaced by a new code of the correct type.

You might think all that needs to be done is to call free on the placeholder node. You could, but then you’d have to ensure that there are no other pointers pointing to it, not only in the tree, but in local variables in stack frames of functions on the call stack lest you get a dangling pointer. Simpler, would be to use arenas.

Arenas

An arena typically is a large chunk of dynamically allocated memory from which actual objects of interest are subsequently allocated from using a custom allocator. There are many ways to implement arenas depending upon the answers to the following questions:

Will all objects that will be allocated from it be of the same type (or at least size) or different types (or sizes)?
Will the maximum number of objects that will be allocated from it be known in advance?
If not, will the arena need to grow as needed?
Will individual objects need to be deallocated from the arena?
Does it need to be thread-safe? (If your particular program doesn’t use threads, then the answer is “no.”)

About the only thing all arena implementations have in common is that freeing the arena frees all objects in it — which is one of the main reasons for using an arena in the first place.

An Arena for Cdecl

In the case of Cdecl, the answers to the previous questions are:

Yes. (All objects are AST nodes.)
No. (Won’t know maximum number of objects.)
Yes. (Will need to grow as needed.)
No. (Individual objects will not need deallocation.)
No. (Does not need to be thread-safe.)

Given those answers, all that’s needed to implement an arena is a simple, singly linked list, something like:

typedef struct slist slist;
struct slist {
  slist *next;
  void  *data;
};

void slist_push_front( slist **phead, void *data ) {
  slist *const new = malloc( sizeof *new );
  assert( new != NULL );
  *new = (slist){ .next = *phead, .data = data };
  *phead = new;
}

Then to put all AST nodes into the arena:

c_ast_t c_ast_new( /* params */, slist **parena ) {
  c_ast_t *const ast = malloc( *ast );
  // ...
  slist_push_front( parena, ast );
  return ast;
}

Finally, to free all AST nodes in one go (which is the whole point):

void slist_cleanup( slist **phead,
                    void (*free_fn)( void* ) ) {
  slist *node = *phead, *next;
  for ( ; node != NULL; node = next ) {
    next = node->next;
    if ( free_fn != NULL )
      (*free_fn)( node->data );
    free( node );
  }
  *phead = NULL;
}

As arenas go, a linked list is pretty simple. It might even be a stretch to call it an arena at all. In the case of Cdecl, it’s good enough — don’t over-engineer things.

More Complex Arenas

A slightly more complex arena would be one where you build on top of the linked list where each node would be a “block” of objects. For example, the first block could hold a maximum of, say, 8 objects. If you run out of space, you can allocate more blocks. Each can either be the same size or double the previous size up to a maximum size:

typedef struct arena arena;
struct arena {
  slist  *blocks;
  size_t  block_size_min, block_size_max;
  size_t  obj_size;
  size_t  avail;
};

void arena_init( arena *a,
                 size_t block_size_min,
                 size_t block_size_max,
                 size_t obj_size ) {
  *a = (arena){
    .block_size_min = block_size_min,
    .block_size_max = block_size_max,
    .obj_size = obj_size
  };
}

A block will store both its size and the memory for objects:

typedef struct arena_block arena_block;
struct arena_block {
  size_t size;
  alignas( max_align_t ) char data[];
};

This uses a flexible array member for the object storage. Given that, we can implement an allocator:

void* arena_alloc( arena *a ) {
  if ( a->avail == 0 ) {
    arena_block *block = arena_node2block( a->blocks );
    size_t block_size;
    if ( block == NULL )
      block_size = a->block_size_min;
    else if ( block->size <= a->block_size_max / 2 )
      block_size = block->size << 1;
    else
      block_size = a->block_size_max;

    block = malloc( sizeof(arena_block) + block_size * a->obj_size );
    assert( block != NULL );
    a->avail = block->size = block_size;
    slist_push_front( &a->blocks, block->data );
  }
  return &a->blocks->data[ --a->avail * a->obj_size ];
}

If a->avail is 0, it means we have to allocate a new block:

Ignoring arena_node2block for now, if block is NULL, there are no blocks, so block_size will be block_size_min.
Otherwise, if doubling block_size won’t exceed block_size_max, then double it.
Otherwise, use block_size_max.

Then allocate memory for a block and block_size objects and push data — not block — onto the head of the linked list of blocks. This makes it simpler to calculate the address of any object in a block as it done on the return line.

The size is “hidden” in memory before the object pointed to by slist’s data. This trick is commonly used in allocators. Indeed, it’s typically how malloc stores the size of a chunk of memory so that it later can be recovered.

But, given an slist* for a block, how can you get at the block’s size? There is where arena_node2block comes in:

static inline arena_block* arena_node2block( slist *node ) {
  return node == NULL ? NULL :
    (arena_block*)(node->data - offsetof(arena_block, data));
}

The expression node->data, being an array, “decays” into a pointer to its first element. In memory, size, as mentioned, is stored before that. You might think that it’s just sizeof(size_t) bytes before node->data — and it could be. The problem is that there may be padding between size and data. To subtract the correct number of bytes that includes the padding (if any), the standard macro offsetof can be used. In this case, it will return the offset of data into the structure that includes the padding (if any).

To implement a deallocator:

void arena_cleanup( arena *a, void (*free_fn)(void*) ) {
  for ( slist *node = a->blocks, *next_node;
        node != NULL; node = next_node ) {
    arena_block *const block = arena_node2block( node );
    if ( free_fn != NULL ) {
      for ( size_t i = a->avail; i < block->size; ++i )
        (*free_fn)( &block->data[ i * a->obj_size ] );
      a->avail = 0;
    }
    free( block );
    next_node = node->next;
    free( node );
  }
  a->blocks = NULL;
}

The code is fairly straightforward. The only thing to remember is that the first block may not be full and you should call free_fn only only actual objects. Hence, we start iterating at a->avail rather than 0; then set a->avail to 0 for the remaining blocks that are all full.

Conclusion

Using arenas for object management can simplify memory management in the special case when an entire collection of objects are all deallocated together. Arenas can also be more performant since it required fewer calls to malloc and free. There are other possible arena implementations in addition to the two presented here. Keep arenas in mind for your next project.

Avoid the Temptation of Bit Fields

Paul J. Lucas — Tue, 27 Jan 2026 01:43:54 +0000

Introduction

Every once in a while, I come across somebody else’s blog post who’s apparently recently discovered bit fields and thinks they’re nifty in that they allow you to pack things like Boolean flags into single bits. One example was along the lines of:

struct status {
  unsigned running : 1;
  unsigned paused  : 1;
  unsigned error   : 1;
};

That is, instead of using three whole bytes (24 bits) to store three Boolean flags, you can use just three bits!

In reality, the original 24 bits would have been padded up to 32 bits and 3 bits would be padded up to at least 8. Hence, at best, you would have saved 24 bits.

While that might seem like a pretty good memory savings, there’s no such thing as a free lunch. With only a very small number of exceptions, such uses of bit fields are both misguided and actually inefficient.

Performance

Since a byte is the smallest directly addressable unit on a computer, in order to access an individual bit or set of bits like:

void set_running( struct status *s ) {
  s->running = 1;
}

the compiler has to generate code equivalent to what you would have done yourself by hand to set just one bit manually. For example, the armv8 generated code (annotated with C pseudocode) is:

ldrb    w8, [x0]     ; char w8 = *x0;
orr     w8, w8, #0x1 ; w8 |= 1;
strb    w8, [x0]     ; *x0 = w8;

That is:

Read the existing value from memory (slow).
Set the bit.
Write the updated value to memory (slow).

For a normal unsigned, you do only step 3. Hence the generated code for either reading or writing bit fields is always slower.

Other Caveats

In addition to the performance penalty, the following things are either unspecified or implementation defined when it comes to bit fields:

Whether the order of the bits is left-to-right or right-to-left. For the above example, the bits could be in the order rpe where r (for running) is the most significant bit or epr where e (for error) is.
How the bytes containing the bit fields are aligned. For the above example, they could be rpeXXXXX or XXXXXrpe.
Whether a multi-bit bit field can straddle a word boundary.
Whether a plain int bit field is signed or unsigned. Ordinarily, int is always signed. As the type of a bit field, int becomes like char in that it’s implementation defined whether it’s signed or unsigned.
Whether types other than int, signed int, unsigned int, _Bool, _BitInt(N), unsigned _BitInt(N), or _Atomic variants can be used as bit fields.

Hence, use of bit fields is extremely not portable.

Appropriate Uses

Given that bit fields are slower and not portable, when is it a good idea to use bit fields?

If you really, really need the memory savings.
If you want code clarity and the performance is inconsequential.
If you need to deal with specific hardware that uses sub-byte fields and you have detailed knowledge of your compiler.

For saving memory, if you have other, non-bit field members in a structure, you can also often save memory by sorting members descending by size to minimize padding.

For code clarity, admittedly code like:

if ( status->error )

is simpler and thus clearer than something like:

if ( (status & ERROR_BIT) != 0 )

So if you really want to trade performance for simplicity and clarity, fine, but fully understand the implications of your choice.

If you need to deal with specific hardware, you can use bit fields to map structures directly to the hardware, but you must ensure that the code your compiler generates is actually what you think it is — that is you have to know the details of what your particular implementation defines for its implementation defined behavior.

Conclusion

Unless you have a specific reason to use bit fields, don’t. Especially don’t just because you think they’re either efficient or nifty.

C23 Miscellany

Paul J. Lucas — Sat, 03 Jan 2026 16:00:03 +0000

Introduction

I’ve written a few articles on individual new features in C23 covering attributes, auto, bool, storage classes for compound literals, constexpr, explicit underlying types for enumerations, nullptr, and typeof. There are a few miscellaneous new features that aren’t substantial enough to warrant individual articles for each, so this article will cover them together.

Aggregate Initialization

You can now initialize aggregates (arrays, structures, and unions) with an empty = { }. Previously at a minimum, you had to include a 0 between the { and }.

Binary Literals

C has had decimal, octal, and hexadecimal integer literals since its creation. C23 adopted binary literals from C++14 using either the same 0b or 0B prefix:

int n = 0b101010;  // 42 decimal

`_BitInt`

A new bit-precise integer type has been added, _BitInt(n) where n is a positive constant integer expression. It may be either signed (the default) or unsigned. (If signed, n includes the sign bit.) Some examples:

unsigned _BitInt(24)  rgb24;   // 24-bit RGB color
unsigned _BitInt(256) sha256;  // SHA-256

The maximum value for n is implementation defined, but is at least as many as for unsigned long long.

Decimal Floating-Point Types

Although they’ve existed as extensions for a while, the new decimal floating-point types of _Decimal32, _Decimal64, and _Decimal128 are now officially supported.

Decimal-floating types are better for calculations involving money (dollars, euros, pounds, etc.) because they’re not subject to the same rounding errors that the standard-floating types are. The standard-floating types are still better for general floating-point calculations.

Declarations After Labels

You can now (finally) put declarations immediately after either goto or case labels:

error:             // C < C23: error; C23: OK
  int code;

Previously, you had to use something like the :; trick (an empty statement after :) to be legal. The C Committee should have made this legal when they allowed intermingled declarations and code in C99, but better late than never.

Digit Separators

C23 also adopted the ' character as a digits separator from C++14 as a readability aid:

int n = 0b0010'1010;
int c = 299'792'458;

The overall value is not affected. You’re free to group the digits however you like.

If you’re wondering why , (comma) wasn’t used, it’s because , is used to separate function arguments and is also the comma operator.

K&R-Style Functions

Even though function prototypes were adopted from C++ way back in C89 (the first ANSI C), C has still supported “K&R style” function declarations and definitions:

char* strncpy();  // C < C23: unspecified arguments

char* strncpy( dst, src, n )
  char *dst;
  char const *src;
  size_t n;
{
  // ...

Finally, C23 has dropped support for such declarations and definitions.

New Keyword Spellings

In addition to bool replacing _Bool, alignas replaces _Alignas, alignof replaces _Alignof, static_assert replaces _Static_assert, and thread_local replaces _Thread_local. (The old spellings are still supported, but deprecated.)

New Preprocessor Directives

The preprocessor now includes #elifdef, #elifndef, #embed, and #warning directives.

Unnamed, Unused Parameters

Unlike C++, function definitions in C have historically required unused parameters to still be named. To eliminate an “unused” warning, you typically cast it to void:

char** cdecl_rl_completion( char const *text,
                            int start, int end ) {
  (void)end;  // means: unused
  // ...

In C23, you can simply omit the name just like you always could in function declarations.

`__VA_OPT__`

Though it’s been supported as an extension by gcc and clang for a while, __VA_OPT__ is finally part of the C standard.

Variadic Functions

As I mentioned in a previous article, variadic functions no longer insist on at least one required parameter; that is you can do:

void f( ... ) {      // C23: no required parameter
  va_list args;
  va_start( args );  // C23: no second argument
  // ...

This ability was adopted from C++.

Conclusion

Of all the changes to C23, auto will probably be the most used; but the other changes, while not revolutionary, are nice (and sometimes long overdue).

bool in C23

Paul J. Lucas — Fri, 19 Dec 2025 02:33:14 +0000

Introduction

Originally, C had no boolean type. Instead, int was invariably used such that 0 was treated as false and any non-zero value was treated as true. While this certainly worked, using int as a boolean has problems.

Problems with `int`

One problem with using int as a boolean is clarity. Consider the function:

int strbuf_reserve( strbut_f *sbuf, size_t res_len );

What does that function return? A simple boolean value? How many bytes were actually reserved? An error code? You have to read the documentation (if any) or the source code (if not — assuming you even have it) to know what the int means. If it returned a boolean instead, it would very likely indicate the success or failure.

Consequently, many programmers, especially those who learned other languages first that had a boolean type (such as ALGOL, Fortran, or Pascal) often defined their own boolean “type” in C, something like:

#define bool   int  /* or: typedef int bool; */
#define false  0
#define true   1

or perhaps all-caps versions. However, that can cause its own problem. If you use a few C libraries from different authors in your program, each might define its own boolean type slightly differently that can lead to incompatibilities, warnings, or errors (depending on how each is defined).

Another problem with int as a boolean is that in structures, it takes up at least four times as much space as needed (assuming 32-bit integers).

Although a true boolean value needs only a single bit, it practically must be sizeof(char) (which is always 1 byte).

`_Bool` in C99

One of the jobs of a language standard committee is to standardize common industry practice to eliminate variances and incompatibilities. Eventually, the C Committee added a boolean type to C — sort of.

In C99, the C Committee finally (after 27 years) added a boolean type to C: _Bool. Why was it spelled like that? Why not simply bool? As I wrote in my book Why Learn C, §2.2, p. 29:

To evolve C, the C committee occasionally adds new keywords. The problem is that every new keyword has the potential to break existing programs because some may already use the same identifier. To help minimize this possibility, the committee decided that new keywords would generally start with an underscore followed by a capital letter (e.g., _Bool, §C.6), at least for a transition period to allow people time to update their programs. Such keywords may look odd, but it’s better than breaking programs.

However, the Committee did not add _False and _True keywords, so you still had to use 0 and non-zero. But they also added stdbool.h that did:

#define bool  _Bool
#define false 0
#define true  1

so you could, at your option, #include that header and use the conventional names. This half measure worked well enough and, more importantly, didn’t break existing programs.

But when C11 with _Generic came out, _Bool didn’t play nice with it:

#include <stdbool.h>

void f_bool() { }
void f_int()  { }

#define F(X)      \
  _Generic( (X),  \
    bool: f_bool, \
    int : f_int   \
  )( (X) )

int main() {
  bool b = false;
  F( b );           // calls f_bool
  F( false );       // calls f_int
}

The call of F passing false calls f_int because false is only a macro for 0 — which is an int.

Another difference between int and _Bool is what happens when certain values are cast:

int   i1 =   (int)0.5;       // = 0 (truncation)
_Bool b1 = (_Bool)0.5;       // = 1 (non-zero -> true)
int   i2 =   (int)LONG_MAX;  // implementation defined
_Bool b2 = (_Bool)LONG_MAX;  // = 1

Unlike int, the semantics of _Bool are more intuitive and always well defined, specifically, any non-zero value always gets implicitly converted to 1 (true).

`bool` in C23

In C23, the C Committee (after 51 years) added a complete boolean type to C: bool (deprecating _Bool). Not only that, but false and true are finally keywords which means the problem with _Generic goes away.

Ideally, the C Committee should have added bool to C11 alongside _Generic — but better late than never.

Conclusion

Despite taking over a quarter of a century for _Bool and over half a century for bool, C finally has a proper boolean type that is clearer and smaller than int and is always well defined.

Advanced C Preprocessor Macros for a Type-Safe Varargs Substitute

Paul J. Lucas — Tue, 16 Dec 2025 03:16:30 +0000

Introduction

As you may know, variadic functions in C are those that can take a varying number of arguments, the most well-known of which is printf and related functions. As you may also know, variadic functions have a number of caveats as I previously explained. Can type-safe variadic arguments be implemented in standard C? Yes!

A Type-Safe Variadic Argument

First, we need a type that can store a value for any one of C’s built-in types — a type-safe variadic argument (TSVA):

enum tsva_type {
  TSVA_BOOL,
  TSVA_CHAR,
  TSVA_SCHAR,
  TSVA_SHORT,
  TSVA_INT,
  TSVA_LONG,
  TSVA_LONG_LONG,
  TSVA_UCHAR,
  TSVA_USHORT,
  TSVA_UINT,
  TSVA_ULONG,
  TSVA_ULONG_LONG,
  TSVA_FLOAT,
  TSVA_DOUBLE,
  TSVA_PTR_CHAR,
  TSVA_PTR_CONST_CHAR,
  TSVA_PTR_VOID,
  TSVA_PTR_CONST_VOID
};
typedef enum tsva_type tsva_type_t;

struct tsva_value {
  union {
    bool                b;

    char                c;
    signed char         sc;
    short               s;
    int                 i;
    long                l;
    long long           ll;

    unsigned char       uc;
    unsigned short      us;
    unsigned int        ui;
    unsigned long       ul;
    unsigned long long  ull;

    float               f;
    double              d;

    char               *pc;
    char const         *pcc;

    void               *pv;
    void const         *pcv;
  };
  tsva_type_t           type;
};
typedef struct tsva_value tsva_value_t;

That is tsva_value uses an anonymous union to store an argument’s value and type to store its type.

For char and void, the union has pointers to those types. Ideally, the union should have T* and T const* for all the built-in types. They were elided here for for brevity.

The union omits the long double type since it might be double the size of double that would double sizeof(tsva_value_t) for a type that’s rarely used.

The union also omits the _Complex floating-point types as well as the new C23 _Decimal32, _Decimal64, and _Decimal128 types since those would also increase sizeof(tsva_value_t) for types that are rarely used.

That said, sizeof(tsva_value_t) doesn’t really matter (as we’ll see). If you need any of the omitted types, feel free to add them.

Using Type-Safe Variadic Arguments

An example of using type-safe variadic arguments might be a function that can print its arguments like printf, but in a type-safe way:

void tsva_print( unsigned n, tsva_value_t const value[n] ) {
  for ( unsigned i = 0; i < n; ++i ) {
    switch ( value[i].type ) {
      case TSVA_CHAR:
        printf( "%c", value[i].c );
        break;
      case TSVA_INT:
        printf( "%d", value[i].i );
        break;

      // Other types ...

      case TSVA_PTR_CHAR:
      case TSVA_PTR_CONST_CHAR:
        fputs( value[i].pc, stdout );
        break;
    } // switch
  }
}

That is, type-safe variadic arguments will be passed as an “array” (really, a pointer). Just as with standard variadic arguments, type-safe variadic arguments leave it to the user to determine how to know how many arguments there are. In this example, the number of elements, n, is passed as an argument also.

But how is such a function called? Specifically, how are the tsva_value_t elements created? We can use some macros:

#define TSVA_INIT(TYPE, FIELD, VALUE) \
  (tsva_value_t){ .type = TSVA_##TYPE, .FIELD = (VALUE) }

#define TSVA_BOOL(VALUE)            TSVA_INIT( BOOL, b, (VALUE) )
#define TSVA_CHAR(VALUE)            TSVA_INIT( CHAR, c, (VALUE) )
#define TSVA_SCHAR(VALUE)           TSVA_INIT( SCHAR, sc, (VALUE) )
#define TSVA_SHORT(VALUE)           TSVA_INIT( SHORT, s, (VALUE) )
#define TSVA_INT(VALUE)             TSVA_INIT( INT, i, (VALUE) )
#define TSVA_LONG(VALUE)            TSVA_INIT( LONG, l, (VALUE) )
#define TSVA_LONG_LONG(VALUE)       TSVA_INIT( LONG_LONG, ll, (VALUE) )
#define TSVA_UCHAR(VALUE)           TSVA_INIT( UCHAR, uc, (VALUE) )
#define TSVA_USHORT(VALUE)          TSVA_INIT( USHORT, us, (VALUE) )
#define TSVA_UINT(VALUE)            TSVA_INIT( UINT, ui, (VALUE) )
#define TSVA_ULONG(VALUE)           TSVA_INIT( ULONG, ul, (VALUE) )
#define TSVA_ULONG_LONG(VALUE)      TSVA_INIT( ULONG_LONG, ull, (VALUE) )
#define TSVA_FLOAT(VALUE)           TSVA_INIT( float, f, (VALUE) )
#define TSVA_DOUBLE(VALUE)          TSVA_INIT( double, d, (VALUE) )
#define TSVA_PTR_CHAR(VALUE)        TSVA_INIT( PTR_CHAR, pc, (VALUE) )
#define TSVA_PTR_CONST_CHAR(VALUE)  TSVA_INIT( PTR_CONST_CHAR, pcc, (VALUE) )
#define TSVA_PTR_VOID(VALUE)        TSVA_INIT( PTR_VOID, pv, (VALUE) )
#define TSVA_PTR_CONST_VOID(VALUE)  TSVA_INIT( PTR_CONST_VOID, pcv, (VALUE) )

Given those, we can call tsva_print like this:

tsva_print( 2, (tsva_value_t[]){
  TSVA_PTR_CONST_CHAR("Answer is: "), TSVA_INT(42)
} );

While that works, it’s a bit ugly and verbose. Let’s see if we can clean that up.

Counting Variadic Arguments

One of the things that makes the current code ugly, not to mention error-prone, is having to count (correctly!) the number of arguments and pass that. Can the number of variadic arguments be counted? Yes:

#define VA_ARGS_COUNT(...) \
  ARG_11(__VA_ARGS__ __VA_OPT__(,) 10, 9, 8, 7, 6, 5, 4, 3, 2, 1, 0)

#define ARG_11(_1,_2,_3,_4,_5,_6,_7,_8,_9,_10,_11,...) _11

As first shown in an earlier article, the ARG_11 macro always returns its 11th argument. This time, however, it’s being used to implement VA_ARGS_COUNT. Just as before, __VA_ARGS__ will “slide” the correct answer (in this case, the number of arguments) into the 11th argument position. Given that, we can now do:

#define tsva_print(...)                     \
  tsva_print( VA_ARGS_COUNT( __VA_ARGS__ ), \
              (tsva_value_t[]){ __VA_ARGS__ } )

Since we’re defining a macro anyway, might as well have it insert the (tsva_value_t[]) compound literal boilerplate code. Now explicitly specifying the count and the boilerplate can be eliminated:

tsva_print( TSVA_PTR_CONST_CHAR("Answer is: "), TSVA_INT(42) );

That’s better, but the required use of the TSVA_ macros is still quite verbose. Can those be eliminated? As it happens, yes (with a caveat).

Deducing the Type of Variadic Arguments

What we need is a way to deduce the type of each argument automatically. As I described in a previous article, _Generic can be used.

However, as noted in that article, each type case for _Generic must be valid C. Here, that means we can’t use the TSVA_ macros because it would attempt to assign a given VALUE to every union field that would either cause warnings (e.g., assigning a floating-point value to .i) or errors (e.g., assuming a pointer value to .f). Instead, we can use helper functions instead of macros:

static inline tsva_value_t tsva__Bool( _Bool value ) {
  return (tsva_value_t){ .type = TSVA_BOOL, .b = value };
}

static inline tsva_value_t tsva_char( char value ) {
  return (tsva_value_t){ .type = TSVA_CHAR, .c = value };
}

static inline tsva_value_t tsva_signed_char( signed char value ) {
  return (tsva_value_t){ .type = TSVA_SCHAR, .sc = value };
}

static inline tsva_value_t tsva_short( short value ) {
  return (tsva_value_t){ .type = TSVA_SHORT, .s = value };
}

static inline tsva_value_t tsva_int( int value ) {
  return (tsva_value_t){ .type = TSVA_INT, .i = value };
}

static inline tsva_value_t tsva_long( long value ) {
  return (tsva_value_t){ .type = TSVA_LONG, .l = value };
}

static inline tsva_value_t tsva_long_long( long long value ) {
  return (tsva_value_t){ .type = TSVA_LONG_LONG, .ll = value };
}

static inline tsva_value_t tsva_unsigned_char( unsigned char value ) {
  return (tsva_value_t){ .type = TSVA_UCHAR, .uc = value };
}

static inline tsva_value_t tsva_unsigned_short( unsigned short value ) {
  return (tsva_value_t){ .type = TSVA_USHORT, .us = value };
}

static inline tsva_value_t tsva_unsigned_int( unsigned int value ) {
  return (tsva_value_t){ .type = TSVA_UINT, .ui = value };
}

static inline tsva_value_t tsva_unsigned_long( unsigned long value ) {
  return (tsva_value_t){ .type = TSVA_ULONG, .ul = value };
}

static inline tsva_value_t tsva_unsigned_long_long( unsigned long long value ) {
  return (tsva_value_t){ .type = TSVA_ULONG_LONG, .ull = value };
}

static inline tsva_value_t tsva_float( float value ) {
  return (tsva_value_t){ .type = TSVA_FLOAT, .f = value };
}

static inline tsva_value_t tsva_double( double value ) {
  return (tsva_value_t){ .type = TSVA_DOUBLE, .d = value };
}

static inline tsva_value_t tsva_ptr_char( char *value ) {
  return (tsva_value_t){ .type = TSVA_PTR_CHAR, .pc = value };
}

static inline tsva_value_t tsva_ptr_const_char( char const *value ) {
  return (tsva_value_t){ .type = TSVA_PTR_CONST_CHAR, .pcc = value };
}

static inline tsva_value_t tsva_ptr_void( void *value ) {
  return (tsva_value_t){ .type = TSVA_PTR_VOID, .pv = value };
}

static inline tsva_value_t tsva_ptr_const_void( void const *value ) {
  return (tsva_value_t){ .type = TSVA_PTR_CONST_VOID, .pcv = value };
}

Given that, we can implement TSVA_VALUE using _Generic:

#define TSVA_VALUE(VALUE)                        \
  _Generic( (VALUE),                             \
    _Bool             : tsva__Bool,              \
    char              : tsva_char,               \
    signed char       : tsva_signed_char,        \
    short             : tsva_short,              \
    int               : tsva_int,                \
    long              : tsva_long,               \
    long long         : tsva_long_long,          \
    unsigned char     : tsva_unsigned_char,      \
    unsigned short    : tsva_unsigned_short,     \
    unsigned int      : tsva_unsigned_int,       \
    unsigned long     : tsva_unsigned_long,      \
    unsigned long long: tsva_unsigned_long_long, \
    float             : tsva_float,              \
    double            : tsva_double,             \
    char*             : tsva_ptr_char,           \
    char const*       : tsva_ptr_const_char,     \
    void*             : tsva_ptr_void,           \
    void const*       : tsva_ptr_const_void      \
  )( (VALUE) )

Now, each type case is the same by returning a pointer to a function. Hence, now you could instead do:

tsva_print( TSVA_VALUE("Answer is: "), TSVA_VALUE(42) );

and the type of each argument is automatically deduced. That’s better in that only a single macro is used, but it’s still verbose. Can those macros be eliminated completely?

Transforming Variadic Arguments

What’s needed is a way for each argument x, to wrap it as TSVA_VALUE(x). Is there a way to have the preprocessor iterate over variadic arguments? Not directly, but you can via more macro voodoo:

#define APPLY_1(MACRO, ARG)        MACRO(ARG)
#define APPLY_2(MACRO, ARG, ...)   MACRO(ARG), APPLY_1(MACRO, __VA_ARGS__)
#define APPLY_3(MACRO, ARG, ...)   MACRO(ARG), APPLY_2(MACRO, __VA_ARGS__)
#define APPLY_4(MACRO, ARG, ...)   MACRO(ARG), APPLY_3(MACRO, __VA_ARGS__)
#define APPLY_5(MACRO, ARG, ...)   MACRO(ARG), APPLY_4(MACRO, __VA_ARGS__)
#define APPLY_6(MACRO, ARG, ...)   MACRO(ARG), APPLY_5(MACRO, __VA_ARGS__)
#define APPLY_7(MACRO, ARG, ...)   MACRO(ARG), APPLY_6(MACRO, __VA_ARGS__)
#define APPLY_8(MACRO, ARG, ...)   MACRO(ARG), APPLY_7(MACRO, __VA_ARGS__)
#define APPLY_9(MACRO, ARG, ...)   MACRO(ARG), APPLY_8(MACRO, __VA_ARGS__)
#define APPLY_10(MACRO, ARG, ...)  MACRO(ARG), APPLY_9(MACRO, __VA_ARGS__)

#define APPLY_FOR_EACH(MACRO, ...) \
  NAME2(APPLY_, VA_ARGS_COUNT(__VA_ARGS__))(MACRO, __VA_ARGS__)

#define NAME2(A,B)                NAME2_HELPER(A,B)
#define NAME2_HELPER(A,B)         A ## B

That is, we can use VA_ARGS_COUNT to count the number of arguments (say, 4), then construct the corresponding APPLY_ macro (say, APPLY_4) that recursively calls APPLY_n for n < 4 in turn. Hence, the APPLY_FOR_EACH macro applies MACRO to each variadic argument. Given that, we can define:

#define tsva_print(...)                      \
  tsva_print( VA_ARGS_COUNT( __VA_ARGS__ ),  \
              (tsva_value_t[]){ APPLY_FOR_EACH(TSVA_VALUE, __VA_ARGS__) } )

and finally do:

tsva_print( "Answer is: ", 42 );

and it just works.

Conclusion

As this extended example once again shows, the C preprocessor has its own weird text processing language inside of C. The highlighted techniques of:

Argument “sliding” as shown in ARG_11; and:
Argument counting via VA_ARGS_COUNT; and:
Transforming arguments via APPLY_FOR_EACH.

are often used in advanced macros. In this case, they can provide type-safe variadic arguments.

Caveats

While the version of this code that uses the explicit macros of TSVA_BOOL, TSVA_CHAR, etc., has no caveats, the version that uses _Generic does, specifically:

char literals are deduced to int, not char; and:
_Bool literals of false and true are also deduced to int, not _Bool. (However, this has been fixed in C23; see below.)

Hence:

char c = '*';
_Bool b = false;

type_print(c);      // prints "*"
type_print(b);      // prints "false"

type_print('*');    // prints "42", not "*"
type_print(false);  // prints "0", not "false"

This isn’t a problem with _Generic. In C, the type of a char literal is simply defined to be int, not char. Prior to C11 when _Generic was added, this never mattered; but now it matters.

The C++ Committee fixed it in C++ because they wanted the ability to overload functions by char and you can’t do that consistently if char variables are of type char but char literals are of type int. The C Committee should have fixed the type of char literals in C11.

Now in C23 with both auto and typeof, the problem is even worse:

auto x = '*';   // deduces int, not char
typeof('*') y;  // type is int, not char

Similarly, when _Bool was added in C99, it was a transitional type. Specifically, false and true were not added as keywords, but only macros as 0 and 1 (integers), respectively, via stdbool.h. At least this has finally been fixed in C23 now that false and true are proper keyword literals for bool.

DEV Community: Paul J. Lucas

A Simple Dynamic Array for C

Introduction

A Simple Dynamic Array

Initialization & Clean-Up

Accessing Elements

Appending Elements

Other Functions

Adding Type Information

Caveat

Verbosity

Conclusion

My Impression of AI in Programming

Introduction

Prompting

Mundane Tasks

Experience

Finding Bugs

What the AI Did Not Do

Implications

Conclusion

Symbolic Constant Conundrum

Introduction

Macros

Enumerations

const

constexpr

Conclusion

include-tidy: A Tool to Enforce Include-What-You-Use

Introduction

include-what-you-use

include-tidy

Introduction

Use of AI

Configuration

Command-Line Parsing

Include Paths

More Command-Line Parsing

Sample include-tidy.toml Configuration File

Data Structures

Algorithm Part 1: Included Files

Algorithm Part 2: Include File Proxies

Algorithm Part 3: Symbols Referenced

Complete vs. Incomplete Types

Macros

The Preprocessor’s ## Operator

Conclusion

A Fix for Time Machine Always Making Full Backups

Introduction

The Fix

Musings on Structure Declarations

Introduction

1. Forward Structure Declaration

2. Ordinary Structure Declaration

3. Unnamed Structure Declaration

4. typedef Unnamed Structure Declaration

5. typedef Structure Declaration

Unions & Enumerations

C++

Conclusion

Why C Requires the “struct” Keyword for Structures

Introduction

Origin Story

C Archeology

Implications

typedef

Unions & Enumerations

Conclusion

Using Arenas for Easier Object Management

Introduction

Arenas

An Arena for Cdecl

More Complex Arenas

Conclusion

Avoid the Temptation of Bit Fields

Introduction

Performance

Other Caveats

Appropriate Uses

Conclusion

`const`

`constexpr`

`include-what-you-use`

`include-tidy`

Sample `include-tidy.toml` Configuration File

The Preprocessor’s `##` Operator

4. `typedef` Unnamed Structure Declaration

5. `typedef` Structure Declaration

`typedef`

`_BitInt`

`__VA_OPT__`

Problems with `int`

`_Bool` in C99

`bool` in C23