Forem: Paul J. Lucas

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.

Avoid the Temptation of Header-Only Libraries

Paul J. Lucas — Mon, 01 Dec 2025 01:33:36 +0000

Introduction

Occasionally, you come across some library that advertises itself as a header-only library, that is all the code is entirely contained in one or more .h files only — no .c files. The claim is that such libraries are simpler to use because all you have to do is #include the headers. Header-only libraries generally fall into a few types, those that provide:

Type-generic declarations and function definitions, e.g., “containers.”
Ordinary declarations and function definitions.

This article is about only the first two types. My claim is that neither justifies making a library header-only. The third type is less common; but when there really are no non-trivial function definitions, then — and only then — are header-only libraries OK.

Type-Generic Container Header-Only Libraries

One thing that occurs in most programming languages is the desire to have type-generic code, that is code whose purpose or algorithms don’t depend on the type of data. Most commonly, this manifests as the desire to have generic “containers,” e.g., arrays, lists, or sets of some type T where T can not only be any type built into the language, but user-defined types as well, e.g., list of integers, sets of strings, etc.

Different languages that support generic containers do so differently, e.g., C++ uses “templates” where type parameters are instantiated at compile-time with specific types, e.g., a list<T> can be instantiated with T = int yielding list<int>.

C has only minimal support for generic code via _Generic and preprocessor macros. Some people try to use these things to implement generic containers by using very long and elaborate macros, e.g.:

#define LIST(T)                                              \
  struct list_node_##T {                                     \
    struct list_node_##T *next;                              \
    T data;                                                  \
  };                                                         \
                                                             \
  struct list_##T {                                          \
    struct list_node_##T *head, *tail;                       \
  };                                                         \
                                                             \
  static void list_init_##T( struct list_node_##T *list ) {  \
  // ...

That is the type T, a macro parameter, forms part of the names of the structures and functions, e.g., list_int.

The benefit of using macros like this is that the code is header only, that is all the code is in a single .h file. While this works, it has a number of problems.

In the earliest days of C++ (C with Classes), macros were used to implement generic containers. The problem with macros in general is that they don’t obey either scope or type rules, nor work well with tools. Hence the addition of templates to C++.

Problems

Using macros to define generic containers has a number of problems:

All functions must be declared static, otherwise every .o file whose corresponding .c file includes the header will contain definitions for all functions. That would result in the linker complaining about duplicate symbols.
While static declarations solve the duplicate symbols problem, every .o file still contains the definitions for all functions that are all present within the final executable. This results in code bloat increasing the executable’s size, sometimes dramatically, both on disk and in memory.
It’s hard to debug the code in the macros themselves since it expands to be a single line of code.

For example, even if you use only one type for T, say, int, hence LIST(int), but include the header into, say, five .c files, then the final executable will have five copies of all the code.

Note that if and only if all functions are marked inline in addition to static and the functions are trivial enough to actually be inlined by the compiler, then the code bloat problem goes away. However, any useful containers library will invariably have non-trivial functions that can’t be inlined.

Mitigation Tactics

For generic code as described, there’s no standard way (meaning, there’s no compiler-independent way) to solve the code bloat problem.

If you’re using gcc or clang, you can use the weak attribute; if you’re using MSVC, you’re out of luck since no equivalent attribute exists.

If you’re working on code only for a specific system or you’re the only user, then fine: you can use compiler-specific solutions; but if you want your code to be widely cross-platform, then you shouldn’t use compiler-specific solutions.

Ordinary Header-Only Libraries

Ordinary header-only libraries have the code that otherwise would have gone into .c files in the .h files instead. To avoid the aforementioned duplicate symbols problem, static is used for everything as before.

One problem this creates is that type and function declarations that would have been “private” to the implementation using static as intended are now “public” that breaks encapsulation.

One problem that creates is that users might use some of the private parts of the implementation when they shouldn’t. If the library author changes any of the private parts, that’ll break user programs.

Mitigation Tactics

One way to fix that would be simply to put comments like:

// PART OF FOO IMPLEMENTATION -- DO NOT USE

Another marginally better way to fix the encapsulation problem is to split the .h file into “public” and “private” parts guarded by a macro like:

// The ".h" part of the library.
// ... type and function declarations ...

// The ".c" part of the library.
#ifdef FOO_LIBRARY_IMPLEMENTATION
// ... function definitions ...
#endif

Then in one .c file of the user’s choosing:

#define FOO_LIBRARY_IMPLEMENTATION
#include "foo_library.h"

The library author is forcing the user to compile the code into some .c file that the author could have simply provided in the first place. The user has to list the .h file as a dependency in their makefiles anyway; also listing the .c file as a dependency is no more of a burden than choosing an existing .c and defining a macro. Hence, it’s not at all clear to me why such a header-only library is allegedly simpler to use.

Other Languages

Of all the programming languages that exist, C is rare in that it was designed such that library “interfaces” and “implementations” are put into separate files, namely .h and .c, respectively. Only a handful of other languages do this: C++, Objective-C, Ada, D, and Modula-2. And of those, only C++ is still widely used.

Conclusion

If you learn any modern language that puts interfaces and implementations into the same file before learning C, you might be tempted to do the same in C — don’t! The hard reality is that C wasn’t designed for and therefore doesn’t really support header-only libraries (whether you like or not). Some day, C might get a proper module facility, but that day is not today. Don’t “fight” against the way C was designed.

For type-generic code, you should implement a library using the generic void* in a conventional .h and .c pair. Since you have to add the .h to your dependencies anyway, also adding the corresponding .c is trivial.

As an alternative to void*, you can use flexible array members to implement generic containers in C, but that’s a story for another time.

For ordinary header-only libraries, just use .c files and build tools and all of the problems mentioned simply go away.

Epilogue

You might be wondering, “Don’t C++ templates have the same problems?” Only partially. First, since templates are part of the language proper and not the preprocessor, a C++ compiler can mark all instantiated functions as weak in whatever manner a given platform needs — but it’s the compiler’s problem, not your problem.

Second, the library implementation can use factorization tricks. For example, all std::list<T*> can be implemented in terms of std::list<void*>, that is the single instantiation of the latter can be used for all pointers regardless of T. There are other tricks possible as well.

Note that with a lot more work, you could probably do some factorization tricks in C as well, e.g., have PTR_LIST(T) that’s implemented in terms of LIST(void*).

References

The Design and Evolution of C++, Bjarne Stroustrup, AT&T Bell Laboratories, Addison-Wesley, Reading, Massachusetts, 1994, §15.1.

Good Git Hygiene Practices

Paul J. Lucas — Thu, 27 Nov 2025 15:45:37 +0000

Introduction

Whether you’re writing code for a personal project or for your day job, you very likely are (or should be) using a source code version control system. That’s most likely Git. While there are many opinions on what the best branching strategy is (that I’m not going to discuss here), there are a few independent things you can do to maintain good Git “hygiene” (that I am going to discuss here).

Background

Over the years, one phenomenon I’ve noticed is that I often end up “under the car” — my own personal term to describe the following situation:

You’re humming along working on some code and you discover a bug in existing code that should be fixed regardless of what you’re currently working on, or needs to be fixed in order to continue working on what you’re currently working on.
You decide to pause what you’re doing and fix that bug.
While working on that bug, you might discover another bug that should be fixed regardless of the current bug.
And so on ....

A slight variation is that, instead of discovering a bug, you realize that some bit of architecture needs to be rearchitected a bit, or a new small feature or other change were done, it would greatly simplify what you were originally working on. So, again, you decide to pause what you’re doing and go and do that first.

I recently experienced this phenomenon again. While working on a fix for an issue in cdecl, I realized that the unrelated enhancement of allowing the -t command-line option to be specified twice to suppress predefining all types would make debugging the original issue easier, so that’s what I did.

Why do I refer to this as “under the car?” It comes from the TV show Malcolm in the Middle, specifically a scene from S03E06, “Health Scare,” 2001. I think that video perfectly captures this phenomenon, that is you start out to do X, but realize you need to do Y (and possibly Z) first. Like Hal, you’ve also very likely experienced this phenomenon in your every-day (non-software) life as well.

What Not to Do

Before getting to what you should do, I’ll mention what you should not do:

You should not simply include either the fix for the unrelated bug or the code for the unrelated feature as part of the code you’re currently working on.

Why not? While it is the least-effort thing you can do, you should not do it because:

It makes the diff for your original code longer. (Ideally, the diff for any change should be as small as possible.)
Should you need to revert, you can’t easily revert your new code independently from the unrelated bug or feature.
Similarly, you can’t easily cherry-pick your new code independently from the unrelated bug or feature.

If you’re working as part of a team, you should also not do it because:

It makes the diff more confusing to reviewers.
It makes testing your changes independently harder on QA.

What to Do Instead

There are a few choices, but the better choice depends on whether you are working by yourself on your own project, or part of a team. If by yourself, you can:

“Stash” your current set of changes in a segregated stack returning the current branch to the way it was before you made any changes.
Fix the other bug or add the other feature and commit the change.
“Pop” the stash from the stack reapplying your previous changes and resume what you were originally working on.

Something like:

$ git stash
# Edit files to fix other bug or add other feature.
$ git add .
$ git commit -m"<message>"
$ git stash pop

If the fix for the other bug or change for the other feature is a bit more involved, you might want to create a separate branch for it, in which case the steps go something like:

$ git stash
$ git checkout master
$ git branch other-bug-fix-branch
$ git checkout other-bug-fix-branch
# Edit files to fix other bug or add other feature.
$ git add .
$ git commit -m"<message>"
$ git checkout master
$ git merge other-bug-fix
$ git checkout original-branch
$ git merge master
$ git stash pop

If you’re using pull requests (PRs), then you’d change the last few lines to:

# ...
$ git commit -m"<message>"
$ git push -u origin other-bug-fix
# Review on web site.
# Merge on web site into master.
$ git checkout master
$ git pull
$ git checkout original-branch
$ git merge master
$ git stash pop

This assumes you use some web user interface (such as that of Github or Gitlab) to do the review and eventual merge of the PR.

The advantage of a separate branch is that you can return to your original branch and keep working on it while your other-bug-fix branch is being reviewed. If the bug fix doesn’t affect the code you were originally working on, you can skip the pull and merge from master.

Note that if you were originally working on a branch other than master, you can simply commit your current (incomplete) changes to that branch rather than stash.

Stash Merge Conflicts

Just as with an ordinary merge, git stash pop can also result in merge conflicts. You fix them as with ordinary merge conflicts, add the conflicted files, and commit.

When a merge conflict occurs, the pop doesn’t actually pop: Git merges the changes from the stash, but leaves the stash on the stack just in case. After you fix the conflicts and commit, you should delete the stash via:

$ git stash drop

Conclusion

If you ever find yourself “under the car,” you can use either stashing or branches to continue work while maintaining good Git hygiene.

Advanced C Preprocessor Macros for a Pre-C23/C++20 __VA_OPT__ Substitute

Paul J. Lucas — Tue, 18 Nov 2025 01:27:42 +0000

Introduction

In _Generic in C, I showed how to implement const function overloading in C via this macro:

#define CONST_OVERLOAD(FN, PTR, ...) \
  STATIC_IF( IS_PTR_TO_CONST(PTR),   \
    const_ ## FN,                    \
    (FN)                             \
  )( (PTR) __VA_OPT__(,) __VA_ARGS__ )

I actually use a macro similar to this in my cdecl project.

This macro makes use of __VA_OPT__ that’s a C23/C++20 feature whereas cdecl requires only C11 at a minimum. Why not just require C23? C23 is still too new and thus not ubiquitous, or many compilers don’t yet default to C23.

That aside, it turns out that many compilers have supported __VA_OPT__ for a while even without C23/C++20. So why is this even an issue? Because it’s not standard and you can’t rely on such support. While this might not keep me up at night, it comes close.

I’ve searched for a long time for a way to simulate __VA_OPT__ using only standard pre-C23/C++20 and found nothing. After continued searching, I’ve finally found all the pieces. To do it requires some “advanced” (sometimes clever, but mostly weird) use of preprocessor macros, so buckle up: it’s going to be a wild ride.

Reminder

As a reminder, what __VA_OPT__ does is fairly simple. In a function-like macro, if the number of arguments given for the variadic parameter is:

Greater than zero, that is __VA_ARGS__ will expand into something that is not empty, then __VA_OPT__ will insert the token(s) given to it;
Zero, that is __VA_ARGS__ is empty, then __VA_OPT__ will do nothing.

Hence, for the CONST_OVERLOAD() macro, __VA_OPT__(,) will insert a comma to separate the first argument (PTR) from the second argument — but only if there is a second argument.

So, how hard can it be to simulate __VA_OPT__? (Spoiler: it’s harder than it might seem.)

Is There a Comma?

One thing that helps a lot is first to determine whether __VA_ARGS__ contains a comma. For example, given:

#define M(...)  /* doesn't matter */

Then whether __VA_ARGS__ contains a comma or not:

M()             // no arguments: no comma
M(a)            // 1 argument: still no comma
M(a,b)          // 2 arguments: 1 comma
M(a,b,c)        // 3 arguments: 2 commas
...

Hence, we have to distinguish between the 0/1 argument case from the 2+ arguments case. To be explicit for, say, a maximum of 10 arguments, we want a “has comma” macro to return either 0 (false) for “no comma” or 1 (true) for “has comma” as given in this small truth table:

#Args: 0/1 2 3 4 5 6 7 8 9 10
Comma?  0  1 1 1 1 1 1 1 1 1

Given that, we can define ARGS_HAS_COMMA():

#define ARGS_HAS_COMMA(...) \
  ARG_11( __VA_ARGS__, 1, 1, 1, 1, 1, 1, 1, 1, 1, 0 )

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

ARGS_HAS_COMMA() uses a helper macro ARG_11() that, given 11 or more arguments (one more than our maximum of 10), always returns its 11th argument.

This implementation self-imposes a maximum of 10 arguments that should be enough for the majority of cases. However, if you want to allow for more, say, 100, change ARG_11 to ARG_101 with 101 parameters followed by ... returning _101 and call it with 99 1s.

What use is always returning the 11th argument? The trick is ARGS_HAS_COMMA() calls ARG_11() supplying its __VA_ARGS__ followed by the above truth table (in reverse). This has the effect of always “sliding” the correct answer into the 11th argument position. For example:

ARGS_HAS_COMMA() => ARG_11( , 1, 1, 1, 1, 1, 1, 1, 1, 1, 0 )

It works as follows:

ARGS_HAS_COMMA() with no arguments causes __VA_ARGS__ to expand into nothing. The preprocessor allows empty arguments, so “nothing” becomes the first argument, the first 1 becomes the second argument (and so on for the remaining eight 1s), and the 0 becomes the 11th argument that’s returned (false).
Similarly, ARGS_HAS_COMMA(x) with one argument causes __VA_ARGS__ to expand into x. This time, the x becomes the first argument, but everything else is the same, i.e., the 0 still becomes the 11th argument that’s returned (false).
However, ARGS_HAS_COMMA(x,y) with two arguments causes __VA_ARGS__ to expand into x,y. This time, x becomes the first argument, y becomes the second argument, the first 1 becomes the third argument (and so on for the remaining eight 1s), and 0 (false) becomes the 12th argument. The 11th argument is the ninth 1 that’s returned instead (true).
For ARGS_HAS_COMMA(x,y,z) with three arguments, the eighth 1 will be returned; and so on for up to 10 arguments.

For this and subsequent examples, you can enter the macros into cdecl and have it expand them for you step-by-step to illuminate how the expansions are taking place.

Is `__VA_ARGS__` Empty?

To answer that question, there are four cases to consider:

Two or more arguments.
An argument within parentheses.
An argument that is a function-like macro that will expand subsequent parentheses that may generate a comma.
Zero arguments, i.e., __VA_ARGS__ is empty.

The 4th case is the one we’re interested in. So why the first 3 cases? They rule out possible false-positives.

The ARGS_IS_EMPTY() macro is:

#define ARGS_IS_EMPTY(...)                                \
  ARGS_IS_EMPTY_CASES(                                    \
    /*  Case 1: argument with a comma,                    \
        e.g. "ARG1, ARG2", "ARG1, ...", or ",". */        \
    ARGS_HAS_COMMA( __VA_ARGS__ ),                        \
    /*  Case 2: argument within parentheses,              \
        e.g., "(ARG)", "(...)", or "()". */               \
    ARGS_HAS_COMMA( ARGS_IS_EMPTY_COMMA __VA_ARGS__ ),    \
    /*  Case 3: argument that is a macro that will expand \
        the parentheses, possibly generating a comma. */  \
    ARGS_HAS_COMMA( __VA_ARGS__ () ),                     \
    /*  Case 4: __VA_ARGS__ doesn't generate a comma by   \
        itself, nor with ARGS_IS_EMPTY_COMMA behind it,   \
        nor with () after it.                             \
        Therefore, "ARGS_IS_EMPTY_COMMA __VA_ARGS__ ()"   \
        generates a comma only if __VA_ARGS__ is empty.   \
        So this is the empty __VA_ARGS__ case since the   \
        previous cases are false. */                      \
    ARGS_HAS_COMMA( ARGS_IS_EMPTY_COMMA __VA_ARGS__ () )  \
  )

Case 1: Two or More Arguments

This is the easy case we’ve already covered, that is:

ARGS_HAS_COMMA( __VA_ARGS__ )

will return 1 (true) only if two or more arguments are given. Hence, this case must return 0 (false) in order for __VA_ARGS__ to be empty.

Case 2: An Argument within Parentheses

This is to handle cases like:

ARGS_HAS_COMMA( (x) )

that is an argument enclosed within parentheses. This is handled by:

ARGS_HAS_COMMA( ARGS_IS_EMPTY_COMMA __VA_ARGS__ )

where ARGS_IS_EMPTY_COMMA is a helper macro defined as:

#define ARGS_IS_EMPTY_COMMA(...)  ,

As a reminder, the preprocessor will expand a function-like macro only if it’s followed by (. Therefore, if __VA_ARGS__ is something like (x), then:

ARGS_IS_EMPTY_COMMA followed by (x) will yield ARGS_IS_EMPTY_COMMA(x).
That will expand into ,.
Then ARGS_HAS_COMMA(,) will yield 1 (true).

However, if __VA_ARGS__ is empty, then:

ARGS_IS_EMPTY_COMMA followed by nothing will stay the same.
Not being followed by a ( means ARGS_IS_EMPTY_COMMA will not expand into ,.
Then ARGS_HAS_COMMA(ARGS_IS_EMPTY_COMMA) will yield 0 (false).

Case 3: Argument that is a Function-Like Macro

This is to handle cases like:

#define FOO(X)  X, 0

that is a function-like macro that expands into something that contains a comma. This is handled by:

ARGS_HAS_COMMA( __VA_ARGS__ () ),

If __VA_ARGS__ is FOO, then:

FOO followed by () will yield FOO(x).
That will expand into X, 0.
Then ARGS_HAS_COMMA(X, 0) will yield 1 (true).

Case 4: Zero Arguments

The first three cases are to filter out false positives. Finally, case 4 answers the question “Is __VA_ARGS__ empty?” This is handled by:

ARGS_HAS_COMMA( ARGS_IS_EMPTY_COMMA __VA_ARGS__ () )

If __VA_ARGS__ is empty, then:

ARGS_IS_EMPTY_COMMA followed by () will yield ARGS_IS_EMPTY_COMMA().
That will expand into ,.
Then ARGS_HAS_COMMA(,) will yield 1 (true).

Putting it All Together

Given those 4 cases, we use a few helper macros:

#define ARGS_IS_EMPTY_CASES(_1,_2,_3,_4) \
  ARGS_HAS_COMMA( NAME5( ARGS_IS_EMPTY_RESULT_, _1, _2, _3, _4 ) )
#define ARGS_IS_EMPTY_COMMA(...)  ,
#define ARGS_IS_EMPTY_RESULT_0001 ,
#define NAME5(A,B,C,D,E)          NAME5_HELPER( A, B, C, D, E )
#define NAME5_HELPER(A,B,C,D,E)   A ## B ## C ## D ## E

where:

We use NAME5 to paste together ARGS_IS_EMPTY_RESULT_ and the results from the four cases yielding a token like ARGS_IS_EMPTY_RESULT_xxxx where each x is either 0 or 1.
If the result is ARGS_IS_EMPTY_RESULT_0001, it’s the result we care about, that is the first three cases ruled out the three false positives (all 0) and the fourth case is 1 (true) meaning __VA_ARGS__ is empty.
The ARGS_IS_EMPTY_RESULT_0001 in turn expands to a ,.
That , is then passed to the outermost ARGS_HAS_COMMA that returns 1 (true) only if __VA_ARGS__ is empty.

If any of the first three false positive cases return 1 (true), then:

That would yield an xxxx that is not 0001, e.g., 0010, 0011, 1000, etc.
That means the result of ARGS_IS_EMPTY_RESULT_xxxx doesn’t expand further.
Which means it doesn’t contain a ,, so the outermost ARGS_HAS_COMMA returns 0 (false) meaning __VA_ARGS__ is not empty.

A `__VA_OPT__` Substitute

Now that we’ve defined ARGS_IS_EMPTY, we can use it to implement a __VA_OPT__ substitute when the compiler doesn’t support it.

The first step is to determine whether the compiler does support __VA_OPT__. This can be done by probing the compiler with TRY_COMPILE:

TRY_COMPILE([__VA_OPT__],
  [#define VA_OPT_TEST(...) __VA_OPT__(int) __VA_ARGS__
  ],
  [int x1 = VA_OPT_TEST() 1; VA_OPT_TEST(x2 = 2);]
)

The first test using x1 ensures __VA_OPT__ is empty if __VA_ARGS__ is.
The second test using x2 ensures __VA_OPT__ is not empty when __VA_ARGS__ isn’t.

If both declarations compile successfully, Autoconf will define HAVE___VA_OPT__ in config.h.

Given that, we can conditionally define our own VA_OPT macro based on whether __VA_OPT__ is supported:

#ifdef HAVE___VA_OPT__
# define VA_OPT(TOKENS,...) \
    __VA_OPT__( STRIP_PARENS( TOKENS ) )
#else
# define VA_OPT(TOKENS,...) \
    NAME2( VA_OPT_EMPTY_, ARGS_IS_EMPTY( __VA_ARGS__ ) )( TOKENS, __VA_ARGS__ )

# define VA_OPT_EMPTY_0(TOKENS,...) STRIP_PARENS(TOKENS)
# define VA_OPT_EMPTY_1(TOKENS,...) /* nothing */
#endif /* HAVE___VA_OPT__ */

The idea is that, instead of the C23/C++20 way of:

__VA_OPT__(,) __VA_ARGS__ // C23/C++20 way

we instead have to do:

VA_OPT( (,), __VA_ARGS__ ) __VA_ARGS__  // our way

It’s unfortunately necessary to have to specify __VA_ARGS__ twice since we need the first __VA_ARGS__ to pass to VA_OPT to see whether it’s empty and the second __VA_ARGS__ for the arguments themselves.

Why can’t the VA_OPT macro simply include __VA_ARGS__ at the end? While __VA_OPT__ commonly precedes __VA_ARGS__, it doesn’t always. For example, a macro that appends a NULL to a comma separated list like:

void func( char const *args[static 1] );

#define func(...) \
  func( (char const*[]){ __VA_ARGS__ VA_OPT( (,), __VA_ARGS__ ) \
        (void*)0 } )

has the __VA_ARGS__ before the VA_OPT because we want , (void*)0 (with a comma) if __VA_ARGS__ is non-empty and just (void*)0 (no comma) if __VA_ARGS__ is empty.

Why use (void*)0 here instead of NULL? Because I want to guarantee a null pointer is passed here. If some platform defines NULL as simply 0 (which is allowed), then 0 will be passed as an int since no type conversions take place for variadic arguments. If sizeof(int) != sizeof(void), the result would be undefined behavior.

The fact that the definition of NULL can vary across platforms is one of the motivations for adding nullptr in C23.

If HAVE___VA_OPT__ is defined, we simply define VA_OPT in terms of the real __VA_OPT__ using the helper macro:

#define STRIP_PARENS(ARG)         STRIP_PARENS_HELPER ARG
#define STRIP_PARENS_HELPER(...)  __VA_ARGS__

that strips the outermost () from its arguments. (Try a few examples to convince yourself that it does just that.)

If HAVE___VA_OPT__ is not defined:

ARGS_IS_EMPTY is used to check whether __VA_ARGS__ is empty yielding either 0 or 1.
That result is then pasted onto the end of VA_OPT_EMPTY_ via the NAME2 helper macro.
If the result is VA_OPT_EMPTY_0 (__VA_ARGS__ is not empty), that expands into STRIP_PARENS(TOKENS) that expands __VA_ARGS__.
If the result is VA_OPT_EMPTY_1 (__VA_ARGS__ is empty), that expands into nothing.

Voilà! You now have VA_OPT that can be used in pre-C23/C++20.

Conclusion

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

Argument “sliding” as shown in ARG_11; and:
Conditional macro expansion like ARG __VA_ARGS__ () by inserting __VA_ARGS__ between a macro and (.

are often used in advanced macros, so it’s good to become familiar with them.

References

Detect empty macro arguments

Autotools Miscellany

Paul J. Lucas — Thu, 13 Nov 2025 23:53:16 +0000

Introduction

This last part in this series on Autotools will cover miscellaneous things in Autotools that don’t really fit anywhere else.

Maintainer Tree

For many software packages, there are typically two versions of its “source tree,” that is the complete set of files that comprise it:

A maintainer tree that contains the complete set of files as checked-out from source control. For git, this means there is also a .git subdirectory containing the files git needs to do what it does.
A distribution tree (or dist tree) that contains the complete set of files resulting from un-tar’ing a downloaded tar file for a particular version of the software, and perhaps other files. A dist tree does not contain a .git subdirectory, but does contain a pre-built configure script.

Sometimes when running configure, you want to be able to perform different actions depending on whether you’re running in a maintainer or dist tree. To be able to tell, you can add the following early in configure.ac:

AS_IF([test -d "$srcdir/.git"], [is_maintainer_tree=yes])

That is, if the .git subdirectory is present, assume it’s a maintainer tree.

What’s an example use? If your program uses programs like Flex or Bison, a dist tree will contain the generated lexer and parser C source files, hence neither Flex nor Bison are required to compile your program which makes it easier for users.

However, a maintainer tree should require Flex and Bison so the lexer and parser can be rebuilt as necessary. To do this in configure.ac:

AS_IF([test "x$is_maintainer_tree" = xyes], [
  flex_min_version="2.5.30"
  bison_min_version="3.4.2"

  AC_PROG_LEX([noyywrap])
  AM_PROG_LEX

  AX_PROG_FLEX([FLEX=$LEX],
    [AC_MSG_ERROR([required program "flex" not found])])
  AX_PROG_FLEX_VERSION([$flex_min_version], [],
    [AC_MSG_ERROR([flex version $flex_min_version or later required])])

  AX_PROG_BISON([BISON=$YACC],
    [AC_MSG_ERROR([required program "bison" not found])])
  AX_PROG_BISON_VERSION([$bison_min_version], [],
    [AC_MSG_ERROR([bison version $bison_min_version or later required])])
])

The AX_PROG_FLEX, AX_PROG_FLEX_VERSION, AX_PROG_BISON, and AX_PROG_BISON_VERSION macros are called only when in a maintainer tree.

C11 Compiler

To require a C compiler that supports at least C11, add an AS_IF after AC_PROG_CC in configure.ac:

AC_LANG(C)
AC_PROG_CC
AS_IF([test "x$ac_cv_prog_cc_c11" = xno], [
  AC_MSG_ERROR([a C11 compiler is required to compile $PACKAGE_NAME])
])

To test for _Generic support specifically:

AC_C__GENERIC
AS_IF([test "x$ac_cv_c__Generic" != xyes], [
  AC_MSG_ERROR([C11 _Generic support required to compile $PACKAGE_NAME])
])

Checking for Functions

If you want to check whether the platform support specific functions, you can use AC_CHECK_FUNCS, e.g.:

AC_CHECK_FUNCS([geteuid getpwuid])

would check for the existence of the geteuid and getpwuid functions. If present, the macros HAVE_GETEUID and HAVE_GETPWUID will be defined in config.h.

Checking for Structure Members

If you want to check whether the platform’s version of a particular struct contains particular member, you can use AC_CHECK_MEMBERS, e.g.:

AC_CHECK_MEMBERS([struct passwd.pw_dir], [], [], [#include <pwd.h>])

would check whether struct passwd contains a pw_dir member. If present, the macro HAVE_STRUCT_PASSWD_PW_DIR will be defined.

For example, a function that determines the user’s home directory is:

char const* home_dir( void ) {
  char const *home = getenv( "HOME" );
#if HAVE_GETEUID && HAVE_GETPWUID && HAVE_STRUCT_PASSWD_PW_DIR
  if ( home == NULL ) {
    struct passwd const *const pw = getpwuid( geteuid() );
    if ( pw != NULL )
      home = pw->pw_dir;
  }
#endif
  return home;
}

That is:

First try the HOME environment variable; if NULL:
If we have geteuid, getpwuid, and the pw_dir member exists, get that value (that’s the user’s home directory).

Conclusion

As stated in the Autotools Introduction, if you’ve ever compiled and installed most any open-source software, you’ve most likely typed the commands:

$ ./configure && make && make install

and it all just works thanks to Autotools. Using Autotools, you can create your own programs that are portable to a wide variety of Unix platforms.

Forem: Paul J. Lucas

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

C23 Miscellany

Introduction

Aggregate Initialization

Binary Literals

_BitInt

Decimal Floating-Point Types

Declarations After Labels

Digit Separators

K&R-Style Functions

New Keyword Spellings

New Preprocessor Directives

Unnamed, Unused Parameters

__VA_OPT__

Variadic Functions

Conclusion

bool in C23

Introduction

Problems with int

_Bool in C99

bool in C23

Conclusion

Advanced C Preprocessor Macros for a Type-Safe Varargs Substitute

Introduction

A Type-Safe Variadic Argument

Using Type-Safe Variadic Arguments

Counting Variadic Arguments

Deducing the Type of Variadic Arguments

Transforming Variadic Arguments

Conclusion

Caveats

Avoid the Temptation of Header-Only Libraries

Introduction

Type-Generic Container Header-Only Libraries

Problems

Mitigation Tactics

Ordinary Header-Only Libraries

Mitigation Tactics

Other Problems

Other Languages

Conclusion

Epilogue

References

Good Git Hygiene Practices

Introduction

Background

What Not to Do

4. `typedef` Unnamed Structure Declaration

5. `typedef` Structure Declaration

`typedef`

`_BitInt`

`__VA_OPT__`

Problems with `int`

`_Bool` in C99

`bool` in C23

Is `__VA_ARGS__` Empty?

A `__VA_OPT__` Substitute