DEV Community: Paul J. Lucas

Program Organization (with Examples in C)

Paul J. Lucas — Tue, 01 Sep 2026 00:54:38 +0000

Introduction

In my book Why Learn C, Chapter 13, Program Organization, I wrote in part:

For all but the most trivial programs, a typical C program is composed of several source (.c) files and header (.h) files. Often, .c and .h files come in pairs where the .c implements some functionality and the .h provides the “public” API for using it. All the functions comprising a program are spread among pairs of files with each pair specializing in some particular aspect of the program. One or more pairs roughly approximates a “module” in other languages.

I also gave an example using the source files of ad:

ad.c     color.h   match.c    options.h     unicode.c  util.h
ad.h     dump.c    match.h    pjl_config.h  unicode.h
color.c  dump_c.c  options.c  reverse.c     util.c

For example, color.c contains the definitions of functions for printing text in color to a terminal and its corresponding color.h contains their declarations so that other files may #include it to use those functions.

The ad example was chosen for the book because it’s a fairly small program where, consequently, the source files and their names make sense once you know what the purpose of ad is. (If you didn’t click the link, ad dumps the contents of any file as ASCII.)

One of the things some newcomers to C (or programming in general using any language) struggle with is how to organize source files. In this article, I’m going to flesh out the details of program organization using a mid-sized program, include-tidy (Tidy), as an example. As a preview, here are its source files:

array.c        file_ext.c         path_util.c       symbol.h
array.h        file_ext.h         path_util.h       toml_lite.c
bit_util.c     fnv1a.c            path_util_test.c  toml_lite.h
bit_util.h     fnv1a.h            pjl_config.h      toml_test.c
clang_util.c   hash_table.c       print.c           trans_unit.c
clang_util.h   hash_table.h       print.h           trans_unit.h
cli_options.c  hash_table_test.c  proxies.c         type_traits.h
cli_options.h  include-tidy.c     proxies.h         typedef.c
color.c        include-tidy.h     red_black.c       typedef.h
color.h        include.c          red_black.h       unit_test.c
config.h       include.h          red_black_test.c  unit_test.h
config_file.c  ipath.c            strbuf.c          util.c
config_file.h  ipath.h            strbuf.h          util.h
cxx.c          options.c          strbuf_test.c
cxx.h          options.h          symbol.c

Compared to ad, Tidy is about three times its size.

Components

Pretty much any program can be broken down conceptually into components. Perhaps one of the most important distinctions between types of components is program-specific vs. generic (or program-agnostic).

Anything that’s “program-specific” is specific to the particular purpose of the program; anything that’s “generic” could conceivably be used in any program regardless of its purpose. Generally, it’s a good idea to:

Minimize the program-specific components because they’re the hardest parts of a program to write (or for others to read and understand — or for yourself in several month’s time) since they’re novel.
Maximize the generic components because they’re easier to write and test; and, over time, you’ll build up your own personal library of code that can be reused in other programs with few, if any, changes.

Many programs have the following components.

Program-specific data structures and algorithms. For Tidy, this includes a data structure to represent a symbol referenced in a program and the header file that declares it.
Generic data structures and algorithms. For Tidy, this includes dynamic arrays, hash tables, red-black trees, and strings buffers. (Such things are necessary in C programs because they don’t exist in C’s standard library.)
Program options. These allow the behavior of your program to be changed. For Tidy, this includes things like what style of comments you want (if any), what column you want to align comments at, whether you want colored output, etc.
Command-line parsing. For Tidy (or any command-line program), parsing command-line options is one way to set program options. There’s often, but not always, a 1:1 correspondence between a program option and a command-line option.
Configuration file parsing. For Tidy (or many programs), parsing a configuration file is another way to set program options — often those that would be too cumbersome to set from the command-line.
Program-specific utilities. These include functions that aren’t totally generic, but are either used in multiple places in a program or make using third-party libraries easier. For Tidy, these include functions for dealing with Libclang.
Generic utilities. For Tidy, these include macros, error-handling functions, string-handling functions, etc.
Test code. For Tidy, this includes a small unit-test framework, test executables, and a functional-test framework.

Program-Specific Data Structures and Algorithms

As mentioned, Tidy includes a data structure to represent a symbol referenced in a program:

/**
 * A symbol referenced in a translation unit.
 */
struct tidy_symbol {
  /**
   * The symbol name with signature (for functions or operators, e.g.,
   * `sqrt(double)`) or template parameters (for templates, e.g.,
   * `std::set<T>`) used as a unique key since C++ allows overloaded
   * functions and specialized templates.
   */
  char const *key;

  /**
   * The symbol name without signature (for functions or operators, e.g.,
   * `sqrt`) or template parameters (for templates, e.g., `std::set`)
   * used in `#include` comments.
   *
   * @note In C++, this is not guaranteed to be unique due to overloaded
   * functions and specialized templates.
   */
  char const *name;

  unsigned    ref_count;              // Number of times referenced.
};

The details of the structure isn’t important here. What’s important is that tidy_symbol and functions to access and manipulate symbols are declared in symbol.h with definitions in symbol.c.

As I wrote about in part 2, IWYU for C++ is much harder to do than for C. I kept adding C++-specific functions to symbol.c until that code comprised approximately one third of the total code. I then decided to move all the C++-specific code to cxx.c with declarations in cxx.h.

If and when such a move is done is entirely subjective, but it puts all the C++-specific code in one place and removes all the C++-specific code from symbol.c making the latter file easier to understand.

The minor caveat of moving code is that the functions declared in cxx.h can no longer be static. This exposes a deficiency in C that doesn’t support better “hiding.” Ideally, the functions declared in cxx.h should be visible only to the code in symbol.c; but static (internal linkage) works only for things in the same .c file and non-static (external linkage) is “public.” However, for a stand-alone program like Tidy, it doesn’t matter.

But if you’re building a library, you ideally want to minimize the symbols that are public. C++ does slightly better than C with namespaces and modules, but even those control only what other C++ code can access, not what symbols are public. For both C and C++, you typically have to resort to compiler-specific attributes or visibility flags.

Tidy also needs some types and a data structure for representing an included file:

/**
 * How to handle an include file.
 */
enum tidy_handling {
  TIDY_HANDLE_DEFAULT,                // Default handling.
  TIDY_HANDLE_ELIDE,                  // Elide even if necessary.
  TIDY_HANDLE_KEEP                    // Keep even if unnecessary.
};

/**
 * Sorting "ranks" when includes are printed.
 *
 * @remarks In order for an include's sort_rank to default to
 * TIDY_SORT_DEFAULT, it's value should be 0 since the value of
 * members whose designated initializers are omitted defaults to 0.
 * Given that, the other values must be negative to sort before the
 * default.
 */
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 enum    tidy_handling   tidy_handling;
typedef struct  tidy_include    tidy_include;
typedef enum    tidy_sort_rank  tidy_sort_rank;

/**
 * A file that was included.
 */
struct tidy_include {
  CXFile          file;               // File that was included.
  CXFileUniqueID  file_id;            // Unique file ID.
  char const     *abs_path;           // Absolute path of file.
  char const     *rel_path;           // Relative path of file.
  tidy_include   *includer;           // Include including this, if any.
  tidy_include   *proxy;              // Proxy include, if any.
  unsigned        depth;              // Include depth.
  array_t         lines;              // Line numbers included from.
  tidy_handling   handling;           // Handle specially?
  tidy_sort_rank  sort_rank;          // Sorting rank.
  bool            is_local;           // Local include file?
  bool            is_needed;          // Is this needed?
  bool            is_proxy_explicit;  // Was proxy explicit?
  hash_table_t    symbol_set;         // Symbols referenced.
};

Similarly, tidy_include and functions to access and manipulate includes are declared in include.h with definitions in include.c.

Eventually, it occurred to me that I’ll need a couple of other program specific data structures:

/**
 * A source file extension and the language it corresponds to.
 */
struct tidy_file_ext {
  char const *ext;                  // Extension (without the `'.'`).
  char const *lang;                 // Language: either `"c"` or `"c++"`.
};

/**
 * An include path given via the `-I` command-line option.
 */
struct tidy_ipath {
  char   *abs_path;                 // The absolute path.
  size_t  abs_path_len;             // Length of abs_path.
};

/**
 * Maps a cursor for either a libclang `TypedefDecl` or a `TypeAliasDecl`
 * to its scoped alias name.
 *
 * @remarks It's necessary to keep a map of cursors for type aliases
 * to their "pretty" scoped alias names.
 *
 * @par Example
 * @parblock
 * Given:
 *
 *      namespace std {
 *        // ...
 *        using ostream = basic_ostream<char>;
 *        // ...
 *      }
 *
 * the type_csr is the entire `using` declaration and alias_name is
 * `"std::ostream"`.  This mapping is needed to include the "pretty"
 * names in include comments.
 *
 * If the file being tidied uses `std::ostream` like:
 *
 *      void f( std::ostream& );
 *
 * then the symbol in the comment will be `std::ostream` and not
 * `std::basic_ostream`:
 *
 *      #include <ostream>          // std::ostream
 *
 * @endparblock
 */
struct tidy_typedef {
  CXCursor    type_csr;             // `TypedefDecl` or `TypeAliasDecl`.
  char const *alias_name;           // Scoped alias name.
};

As before, declarations are in file_ext.h, ipaths.h, and typedefs.h with definitions in file_ext.c, ipaths.c, and typedefs.c, respectively.

Generic Data Structures and Algorithms

As mentioned previously, generic data structures like dynamic arrays, hash tables, red-black trees, and strings buffers are also needed since such things don’t exist in C’s standard library. Each of these is in its own .h/.c pair, i.e., array.h and array.c, hash_table.h and hash_table.c, red_black.h and red_black.c, and strbuf.h and strbuf.c, respectively.

Program Options

As mentioned, these allow the behavior of your program to be changed. For Tidy, these are declared in options.h with definitions in options.c. Before the options themselves, we need a few additional types for some options:

/**
 * Which symbols and in what order to include in a comment.
 */
enum tidy_comment {
  TIDY_COMMENT_SYM_ALPHA,               // Sorted alphabetically.
  TIDY_COMMENT_SYM_LENGTH,              // Sorted by name length, ascending.
  TIDY_COMMENT_SYM_MOST_REF,            // Only most-referenced symbol.
  TIDY_COMMENT_SYM_REF_COUNT            // Sorted by ref. count, descending.
};

/**
 * When to exit with a non-zero status code.
 */
enum tidy_error {
  TIDY_ERROR_IF_VIOLATIONS,             // Non-zero if violations.
  TIDY_ERROR_ALWAYS,                    // Always exit with non-zero.
  TIDY_ERROR_NEVER                      // Always exit with zero.
};

/**
 * Verbose mode.
 */
enum tidy_verbose {
  TIDY_VERBOSE_NONE,                          // Don't be verbose.
  TIDY_VERBOSE_ARGS                = 1 << 0,  // Command-line arguments.
  TIDY_VERBOSE_CONFIG_FILES        = 1 << 1,  // Configuration files.
  TIDY_VERBOSE_CONFIG_SYMBOLS      = 1 << 2,  // Configuration symbols.
  TIDY_VERBOSE_CURSORS             = 1 << 3,  // Libclang cursors.
  TIDY_VERBOSE_DIRECTORY           = 1 << 4,  // Changing directory.
  TIDY_VERBOSE_INCLUDES            = 1 << 5,  // Files included.
  TIDY_VERBOSE_PROXIES_EXPLICIT    = 1 << 6,  // Explicit include proxies.
  TIDY_VERBOSE_PROXIES_IMPLICIT    = 1 << 7,  // Implicit include proxies.
  TIDY_VERBOSE_SRC_FILE_VIOLATIONS = 1 << 8,  // Source file in violation.
  TIDY_VERBOSE_SRC_FILE_ALWAYS     = 1 << 9,  // Always source file.
  TIDY_VERBOSE_STATISTICS          = 1 << 10, // Print statistics?
  TIDY_VERBOSE_SYMBOLS             = 1 << 11, // Symbols referenced.
};

typedef enum tidy_comment tidy_comment;
typedef enum tidy_error   tidy_error;
typedef enum tidy_verbose tidy_verbose;

The tidy_verbose enumeration uses bit-flag values. As I mentioned:

Rather than specify power-of-2 values explicitly, e.g., 0, 1, 2, 4, 8, etc., a common practice is to use 1 << N where N is the Nth bit from 0 to however many bits are needed and let the compiler do the calculation for you.

The options themselves are:

extern unsigned     opt_align_column;     // Comment alignment column.
extern bool         opt_all_includes;     // Print all includes?
extern color_when   opt_color_when;       // When to colorize.
extern char const  *opt_comment_style[2]; // Comment delimiters to use.
extern tidy_comment opt_comment_symbols;  // How to list symbols in comments.
extern bool         opt_config_layers;    // Do configuration file layering?
extern char const  *opt_config_path;      // Configuration file path.
extern bool         opt_debug;            // Print debugging output?
extern tidy_error   opt_error;            // When to exit with non-zero.
extern unsigned     opt_line_length;      // Line length.
extern tidy_verbose opt_verbose;          // Print verbose output?

The option types are declared in options.h and defined in option.c along with functions to parse text and convert its value into a given option, that is for every option opt_X, there exists a function opt_X_parse( char const* ).

Note that the task of getting option values from the user is separate since in Tidy’s case options can be set either from the command line or a configuration file.

Command-Line Parsing

Most any non-trivial program (even a GUI program) has to parse the command-line for arguments and options. While the arguments and options are program-specific, the code to parse them is generally boilerplate. The declarations for this code is in options.h with definitions in options.c.

Configuration File Parsing

Many non-trivial programs also have to parse a configuration file. Rather that use a Tidy-specific format, Tidy uses TOML. Completely generic TOML-parsing code is declared in toml_lite.h with definitions in toml_lite.c and code that uses it to parse TOML-specific configuration is declared in config_file.h with definitions in config_file.c.

By splitting configuration file parsing into generic and program-specific components, the TOML parser can be reused elsewhere.

Program-Specific Utilities

Tidy has many functions that make using Libclang easier in a semi-specific yet generic way. For example:

/**
 * If \a cursor represents either a pointer or reference, gets the
 * cursor for the type to which it either points to or refers,
 * respectively.
 *
 * @param cursor The cursor.
 * @return Returns the cursor for the type to which \a cursor either
 * points to or refers, respectively; or \a cursor if it's neither
 * a pointer nor reference.
 */
CXCursor tidy_Cursor_getUnderlyingType( CXCursor cursor );

That is, given a cursor (Libclang’s term for a pointer to a particular node in the AST of the parsed translation unit) for a type like T*, returns the cursor for T. Such a function is program-specific in that Tidy needs such a function, yet its implemented in a generic way such that any program that needs such a function could use it. Such functions are declared in clang_util.h with definitions in clang_util.c.

Even though I personally prefer using a more traditional K&R style of naming things using snake case, Libclang uses an OOP version of camel case. I therefore named my utility functions to mimic Libclang’s style replacing the clang_ prefix with tidy_ to make it obvious that the function is not in the Libclang library.

Generic Utilities

Any non-trivial program eventually has a util.h and util.c pair containing miscellaneous, generic utilities, including handy macros and functions.

The important point is that nothing in those files should be specific to your program nor in any way depend on program-specific headers. This makes them easy to copy into other programs as-is.

If you have several related generic macros or functions, you might consider splitting those off into separate headers and corresponding .c files. For example, Tidy also has type_traits.h containing several C++-like type-traits macros, bit_util.h containing a few bit-testing functions, and path_util.h contains several path-related functions.

How many related macros or functions should you have before splitting them off? It’s largely subjective, but I’d say at least three.

Conclusion

I hope this extended example of how code was organized into source files in a mid-size program like Tidy helps you organize the code in your own programs. While the example uses C, the components and organization apply to most any program in most any language.

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

Paul J. Lucas — Mon, 10 Aug 2026 12:11:09 +0000

Introduction

In a previous post, I described include-tidy (Tidy), a tool that enforces the include-what-you-use (IWYU) principle for C and C++ programs, 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.

The rules of the principle seem obvious and simple — trivial, even. As I described previously, things like complete vs. incomplete types and preprocessor macros complicated the implementation somewhat, but not crazily so.

I had done pretty the bulk of my testing on C source files including having Tidy run on itself. I (in what would turn out to be naively) thought that C++, at least in terms of referencing symbols and including the header files that declare them, would be largely the same. That is, despite the huge language differences, in C++, symbols are still symbols and headers are still headers.

Then out of the blue, someone e-mailed me a bug report for SWISH++ with a patch. I had originally written SWISH++ back in the late ’90s, but hadn’t touched it in over a decade. I decided to try Tidy on it. I naturally expected some IWYU violations, but I got several dozen. While surprising, I thought I’d just fix them. After examining a few, I started to realize that applying IWYU to C++ is a much harder problem!

When writing C++ code and you need to refer to a symbol, you just instinctively include the header that defines it. It turns out that actually codifying that instinct for C++ is hard because there are actually several “obvious” exceptions to IWYU for C++ that simply don’t exist in C.

Why IWYU for C++ is Harder

Nested Types and Inheritance

Probably the top two things that make IWYU for C++ hard are that C++ allows nested types and inheritance. For example, given:

// Base.hpp
struct Base {
  using value_type = int;
  Base( value_type );
  void b();
  // ...
};

// Derived.hpp
#include "Base.hpp"
struct Derived : Base {
  Derived( value_type );
  void d();
};

// Derived.cpp
#include "Derived.hpp"
Derived::Derived( value_type n ) : Base{ n } {
}

void Derived::d() {
  b();
}

Any C++ programmer would look at this code and say that the #includes are exactly they way they should be: Derived.cpp implements functions for Derived so it includes Derived.hpp; Derived.hpp derives from Base so it includes Base.hpp; no more, no less. Easy, peasy.

But Derived.cpp directly references value_type, Base, and b(), all of which are declared in Base.hpp. So if you naively enforce IWYU, you’d say that Derived.cpp must include Base.hpp. Except no C++ programmer would think that because:

Derived.cpp includes Derived.hpp that defines Derived that inherits value_type from Base. In order to declare Derived in the first place, Derived.hpp had to include Base.hpp because Derived is-a Base. Hence, the transitive include of Base.hpp into Derived.cpp is sufficient.
The same is true for Base and b(): the transitive include of Base.hpp is sufficient.

In C, neither nested types nor inheritance exist, so neither do these cases.

Functions and Derived Arguments

Consider this addition to the previous example:

// Base.hpp
// ...

bool operator==( Base const&, Base const& );

// Derived.cpp
// ...

void f( Derived const &i, Derived const &j ) {
  if ( i == j )
    // ...
}

Similarly to before, Derived.cpp directly references operator==() that’s declared in Base.hpp. So again, if you naively enforce IWYU, you’d say that Derived.cpp must include Base.hpp. Except again, no C++ programmer would think that because:

Derived is-a Base and in order to declare Derived in the first place, Derived.hpp had to include Base.hpp.
The inheritance means that any operator (or function) that accepts a Base as an argument should also accept Derived as an argument.

Again, this means that the transitive include of Base.hpp is sufficient.

Specifically, for any function (or operator) f, you can’t decide immediately whether the header that declares it is required. Instead, you have to defer it until after you’ve examined all of its arguments. If the function:

Has one or more arguments; and:
At least one of those arguments’ type is derived from a relevant base.

then the header is not required: again, the transitive include is sufficient. Similarly in C, this case doesn’t exist: if you reference a function, then the header that declares it is required — period.

Nested Types and Aliases

Consider this example:

// int_set.hpp
#include <set>
using int_set = std::set<int>;

// Foo.cpp
#include "int_set.hpp"

void f() {
  int_set::value_type v;
  // ...
}

Foo.cpp directly references value_type that’s declared in <set>. In this case, there is no inheritance at all, just a type alias. So again, if you naively enforce IWYU, you’d say that Foo.cpp must include <set>. Except again, no C++ programmer would think that because:

In order to declare int_set in the first place, int_set.hpp had to include <set>.
That aside, the point of using a type alias is to hide what the underlying type is, hence the fact that int_set is-a std::set should be irrelevant.

Therefore, Foo.cpp should not be required to include <set>; again, its transitive include is sufficient.

Conclusion

Implementing IWYU for C++ turned out to be a much harder problem that I originally thought several months ago.

I’ve recently released include-tidy 2.0 that has vastly improved C++ support. Even though SWISH++ now has no IWYU violations, it was written in an older version of C++. As time permits, I’ll modernize the code to a more recent version of C++ and won’t be surprised if there are other special case exceptions to IWYU for C++.

Into the void

Paul J. Lucas — Sat, 08 Aug 2026 02:23:26 +0000

Introduction

The static keyword is often cited as the most over-used keyword in C and C++. In C, there are three uses. I only recently realized that the void keyword has four uses. I mean, I knew the four circumstances in which you’d use void, but it never “clicked” in my head that there were four uses — and that’s greater than static’s three. I think it’s because all of void’s uses are somewhat related to “nothingness” whereas static’s uses are largely unrelated, hence more noticeable.

History

Originally, C didn’t have the void keyword. To write a function that didn’t return a value, you could simply omit the return type:

print_locus( file, line, col, msg )
  char *file, *msg;
{
  printf( "%s:%d,%d: %s", file, line, col, msg );
}

This function is written in the original “K&R” dialect of C — before function prototypes were adopted from C++ — where parameters were specified twice: the first time for the order, and the second time for the types. Any parameter not explicitly given a type was presumed to be int; any function not explicitly given a return type was presumed to return int.

You could even omit the return statement. In those days, C compilers were fairly lax about enforcing things (hence the creation of lint). But the compiler still generated a machine instruction to return a (garbage) value. Since the caller wasn’t expecting a return value anyway, it worked out. If you wanted to write marginally cleaner code, you’d just return 0.

This state of affairs, specifically that there was no way to state explicitly that a function returned no value, annoyed Stephen Bourne (yes, the creator of the Bourne Shell). After complaining to Ritchie, and Ritchie realizing that not returning anything from a function could save one machine instruction, void (Bourne’s suggested name) was added to C.

Since then, void slowly had use-cases added to it. It’s also influenced and been adopted by other languages including C++ (obviously), C#, Java, D, and Swift (though Swift spells it Void with a capital “V”).

Function Prototypes

Perhaps the biggest influence C++ had on C was the backporting of function prototypes. In K&R C, if you declared (not defined) a function at all, it was only because it returned a type other than int:

double sqrt();  // K&R C: no parameter information!

Function declarations declared only its return type; its parameters were not declared at all. You just had to ensure that you called the function with the right types.

C++ added function prototypes because Bjarne wanted the ability to overload functions based on their arguments. But prototypes are also very useful for ensuring that the number and types of arguments actually match a function’s parameters. Hence, they were back-ported to C.

But in C++, a function declared like f() means f takes no parameters whereas in K&R C, all it meant was that f was a function (with no information about its parameters at all).

To add prototypes to C yet still allow existing C code for backwards compatibility, void was re-used, e.g., f(void) means f takes no parameters in C — not that f takes one parameter of type void since you can’t declare either a variable or parameter of type void.

To increase compatibility between C and C++ header files, f(void) means the same thing in C++ though the use of void is otherwise unnecessary.

Pointers

Although void objects can’t exist, you curiously can have pointers to void, e.g., void *p. Such pointers are use to point to anything (the opposite of nothing), but the actual type is unknown. As such, you can never dereference a void pointer.

Before void in K&R C, char*, in addition to pointing at either a single character or more commonly an array of characters, i.e., a string, was also used to point to anything, i.e., a chunk of bytes. However, using void* is much clearer (even though you often have to cast a void* to a char* anyway so you can increment it).

Casting

The last use is casting to void. There are actually two use-cases. One is making it clear that you’re intentionally discarding the return value of a function (that doesn’t return void):

(void)printf( "hello, world!\n" );

Such a use means you’re calling the function only for its side effects.

Did you even realize that printf returns a value? It returns the number of characters printed. This can actually be useful when you’re trying to line-up columns in multiple lines of output.

Such a use is rare and is mostly for the benefit of the human reader, not the compiler. One exception is if the function is declared [[nodiscard]], but you want to discard its return value anyway.

The other use-case is casting a parameter to void as is done here in cdecl:

static bool c_ast_visitor_type( c_ast_t const *ast,
                                user_data_t user_data ) {
  (void)user_data;
  // ...
}

This means that you’re intentionally not using the value of a parameter, i.e., casting its value to “nothing.” This also suppresses a warning that the parameter isn’t used. (In C23, you can simply omit the parameter’s name; in C++, you always could.)

Conclusion

So now you know that void, not static, is the most over-used in C. The reason for over-use of keywords in general is that adding any new keyword to a language breaks existing programs because somebody, somewhere, used it to name something. In void’s case, the different uses are at least mostly related to “nothingness.”

A Generic min Function in C

Paul J. Lucas — Sun, 05 Jul 2026 13:57:28 +0000

Introduction

If you’ve programmed any length of time in C, you’ve likely written a macro that returns the minimum of two values like:

#define MIN(I,J)  ((I) < (J) ? (I) : (J))

As I’ve explained in the macro article, all those parentheses should be used to ensure operator precedence as you expect. Even so, the problem of side effects occurring multiple times is still a problem:

int mf = MIN( f(), g() );  // either f or g called twice
int mn = MIN( ++i, j );    // undefined behavior

The second example above is worse because incrementing the same variable more than once in the same expression results in undefined behavior.

Functions

To eliminate side effects occurring more than once, a function can be used instead. But because C lacks templates like C++, multiple functions need to be written. At a minimum, you need:

static inline long long min_ll( long long j, long long j ) {
  return i < j ? i : j;
}

static inline unsigned long long min_ull( unsigned long long j,
                                          unsigned long long j ) {
  return i < j ? i : j;
}

static inline double min_d( double i, double j ) {
  return i < j ? i : j;
}

static inline long double min_ld( long double i, long double j ) {
  return i < j ? i : j;
}

where min_ll will handle all signed integers, min_ull will handle all unsigned integers, min_d will handle float and double, and min_ld will handle long double.

We’re going to ignore _Complex, _Decimal32, _Decimal64, and _Decimal128 types. _Complex is typically used only in specialized programs for math or physics, and the decimal types are typically used only in finance. If wanted, they’re left as trivial exercises for the reader.

You could use min_ld to handle both float and double, but long double is typically less performant than either, so casting all floating point values to long double isn’t a good idea.

These should be declared inline and put into a header (.h) file. You can get away with making them static rather than having to use extern inline in a .c file since no self-respecting C compiler will refuse to inline such trivial functions at least with optimization.

If you want to reduce the verbosity, you can use a helper macro like:

#define MIN_IMPL(T,SUFFIX) \
  static inline T min_##SUFFIX( T i, T j ) { return i < j ? i : j; }

MIN_IMPL(long long, ll)
MIN_IMPL(unsigned long long, ull)
MIN_IMPL(double, d)
MIN_IMPL(long double, ld)

#undef MIN_IMPL

`_Generic`

Additionally, _Generic can be used to give a veneer of function overloading so that we can simply write:

auto m = min( i, j );

and it will “just work” regardless of the types of i and j. Here’s the macro:

#define min(I,J)                  \
  _Generic( (I) + (J),            \
    int               : min_ll,   \
    long              : min_ll,   \
    long long         : min_ll,   \
    unsigned int      : min_ull,  \
    unsigned long     : min_ull,  \
    unsigned long long: min_ull,  \
    float             : min_d,    \
    double            : min_d,    \
    long double       : min_ld    \
  )( (I), (J) )

The (I) + (J) is a common trick with _Generic to use the “usual arithmetic conversions” to determine the common type when the types of I and J are not the same. (As a reminder, _Generic does not evaluate the expression just like sizeof doesn’t.) The trick also promotes smaller integral types like char and short to int (or to unsigned int if char is unsigned) so we don’t need explicit cases for those.

Some astute readers might object and ask:

Doesn’t referencing function names in the expressions cause their addresses to be taken thereby preventing the compiler from inlining calls to them because they’re now being called via pointers-to-function?

Fortunately, no. Remember that _Generic happens at compile time, so in this case, the compiler substitutes the entire _Generic expression with a direct call to the chosen inline function.

Conclusion

Using _Generic and the usual arithmetic conversions, a minimal, type-safe, undefined-behavior-safe min function can be implemented in C.

Another Tale of Two Threads (C or C++ vs. Python)

Paul J. Lucas — Fri, 03 Jul 2026 13:44:33 +0000

Introduction

This article is sort-of a sequel to A Tale of Two Threads (APIs), but this time it’s about a significant difference between either C or C++ and Python threads. If you’re either a C or C++ programmer who’s dabbling with Python threads, you should be aware of what follows.

For the purposes of this article, all of POSIX threads (aka, pthreads), standard C threads, and standard C++ threads can be considered equivalent and will all be referred to simply as pthreads. (On POSIX systems, both C and C++ threads are typically implemented as a thin layer on top of pthreads anyway.)

Background

During my career, I’ve mostly used pthreads from either C or C++ programs. I’m not a Python expert. At most, I’ve written a handful of scripts in Python, the longest of which was around 350 lines, and none used threads.

I have a love-hate relationship with Python. No, it has nothing to do with Python using the off-side rule. Primarily, I dislike that Python isn’t statically typed.

In late 2024 (after officially retiring), I agreed to do some work part-time for an application written in Python that necessarily makes heavy use of threads. Python has its own threading library that looks like pretty much every other threading library and apparently contains no surprises for a C or C++ programmer. Apparently.

Threads in C and C++

Either a C or C++ programmer would know that when either:

main() returns; or:
Any function calls exit.

then the entire process terminates immediately.*

* In C and C++, atexit handlers are performed before termination; in C++, destructors for global objects are also performed. But this doesn’t matter for this article.

As I previously wrote:

Even though nascent “threads” appeared as early as 1966, they weren’t supported by any major programming language of that era. POSIX threads, aka pthreads (“pea-threads”), didn't appear until 1995. Consequently when C was created in 1972, it didn’t support threads at all until pthreads came along.

One consequence of this is that the addition of pthreads couldn’t change the behavior of either 1 or 2 above, that is the process still terminates even if other threads are still running.

To prevent #1 from happening, the main thread (which is the thread main runs on) has to join every thread it created.

Threads in Python

The significant difference in Python is that the main thread will wait until all (non-daemon) threads have terminated, i.e., it does an implicit join on all of them.

Consequently, this means that, unless you either need to synchronize with or want the return values from threads’ main functions, you don’t need to join them yourself explicitly.

If you’re a native Python programmer, this likely isn’t news to you; but for a C or C++ programmer, it might be. It was to me.

As it happens, Java handles threads the same way as Python. Go and Rust handle threads the same way as C and C++.

Conclusion

If you’re doing thread programming and are coming from either C or C++ to Python, know that process lifetime is handled differently.

Why does Python (and Java) handle threads differently? On the whole, the behavior makes thread programming slightly easier.

Pointers and Tuning and Loops! Oh My!

Paul J. Lucas — Thu, 18 Jun 2026 21:34:39 +0000

Introduction

While all code should be efficient, code for library-like components, especially involving loops, should be as efficient as possible since such code is often widely used.

In my A Simple Dynamic Array for C, I included the source code for a function to clean-up a dynamic array:

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 );
}

While this code is correct and good enough for pedagogical purposes, it’s not optimal. Before I tell you why, see if you can figure out why. Hint: it has to do with the use of both the array pointer and the function call in the loop.

For those who might not get the reference in this article’s title, it’s a play on a line from The Wizard of Oz. The original line was “Lions and tigers and bears! Oh, my!”

Loop Refresher

In C (and languages inspired by C including C++, C#, Go, and Java), for loop conditions are reevaluated on every loop iteration. For example, in:

for ( int i = 0; i < n; ++i )

the condition i < n is evaluated on every iteration. That means if n is changed within the loop, it could terminate either earlier or later than it was initially supposed to — and this is well-defined behavior.

This is in contrast to some older languages like Fortran and Pascal as well as some newer languages like Rust where the loop’s termination value is evaluated once just prior to the start of the loop. For example, in Pascal:

for i := 1 to n do

is actually treated as if it were this:

limit := n;
for i := 1 to limit do

Note that if the loop condition is a more complicated expression, such as calling a function:

for ( int i = 0; i < f(x); ++i )

then the function will be called on every loop iteration.

Except if the function is marked as unsequenced in C23 in which case the compiler can hoist its call out of the loop.

(Have you figured out the “why” yet?)

Pointers

Wherever pointers are involved, things get more complicated. From an optimization perspective, pointers are like sand in your gears. Returning to the loop in array_cleanup:

for ( size_t i = 0; i < array->len; ++i ) {
  (*free_fn)( element );
  element += array->esize;
}

That gets compiled by clang into this x86-64 assembly:

.LBB0_4:
    mov  rdi, r15
    call r14                       ; (*free_fn)( element )
    add  r15, qword ptr [rbx + 8]  ; element += array->esize
    inc  r12                       ; ++i
    cmp  r12, qword ptr [rbx + 16] ; i < array->len
    jb   .LBB0_4

The things to notice are the qword ptr lines which means the code has to dereference array (which means read from memory) twice on every iteration. That’s slow.

The problem is that the compiler can’t know for sure that the array object pointed to by array isn’t modified by the function pointed to by free_fn. For all the compiler knows, the function has access to a global copy of the pointer and could modify the array. Compilers have to play it safe.

If there were no function call in the loop, then the compiler could safely hoist both len and esize outside the loop as if the code were:

size_t const esize = array->esize;
size_t const len = array->len;
for ( size_t i = 0; i < len; ++i ) {
  // ... do something other than call a function ...
  element += esize;
}

At best, the compiler can put esize and len into registers; but even at worst, if the compiler puts them into local variables, it would still save two pointer dereferences per iteration.

`restrict` Revisited

Is there any way to tell the compiler that free_fn won’t modify the array? Why yes, there is: restrict:

void array_cleanup( array_t *restrict array,
                    array_free_fn_t free_fn ) {
  // ... otherwise the same as before ...
}

(If you are unfamiliar with restrict, you should read my previous article about it first.)

Even if you are familiar with restrict, you may be surprised to learn that it can help in this case. The canonical use case for restrict is memcpy:

void* memcpy( void *restrict dst, void const *restrict src, size_t n );

where there are two pointers marked restrict which means that they do not point to overlapping regions of memory, i.e., they don’t overlap with each other.

But in the case of array, how can restrict help when there is no other pointer in array_cleanup for array not to overlap with?

It turns out that restrict is more general than you might think. What the restrict in the modified array_cleanup means is that, during its execution, the dynamic array pointed to by array will not be modified by any pointer anywhere in the program, even if free_fn has a copy of such a pointer. Using restrict is a promise you make to the compiler. (If you break that promise, even unintentionally, the result is undefined behavior.)

With restrict, the assembly becomes:

.LBB0_4:
    mov  rdi, r12
    call r14                      ; (*free_fn)( element )
    add  r12, qword ptr [rbx + 8] ; element += array->esize
    dec  r13                      ; --i
    jne  .LBB0_4                  ; i > 0

The compiler has eliminated the array->len dereference and is now counting down to zero.

But why didn’t the compiler optimize the remaining dereference (qword ptr) for esize?

First, similar to inline, restrict can be ignored by the compiler. Second, every CPU has only finite resources, most notably registers. In this case, the compiler presumably thought that the overall performance would still be better even if esize were not put into a register. If it were to be put into a register, then the compiler would have to ensure that it’s value is the same after free_fn is called as before — and presumably that was more costly than a dereference.

As I noted in my restrict article, restrict isn’t yet part of standard C++; however, many compilers support __restrict__ as an extension.

Explicit Caching

Of course you can forget about restrict and just use local variables to cache the values as was done initially:

size_t const esize = array->esize;
size_t const len = array->len;
for ( size_t i = 0; i < len; ++i ) {
  (*free_fn)( element );
  element += esize;
}

Then, despite the function call in the loop, the assembly becomes:

.LBB0_4:
    mov  rdi, rbx
    call r14      ; (*free_fn)( element )
    add  rbx, r13 ; element += esize
    dec  r15      ; --i
    jne  .LBB0_4  ; i > 0

with no dereferences.

In this case, the explicit use of local variables gave the compiler a “nudge” in what turns out to be the right direction for optimization. It’s entirely possible that the compiler could have decided to eliminate the local variables and return to doing a dereference if it concluded that was really better. But by using local variables, you’ve at least told the compiler that the dynamic array pointed to by array will not be modified in the loop — you’ve given the compiler more information to make a better informed decision.

Conclusion

If you want to optimize code using pointers, functions, and loops, consider using either restrict or explicit caching. But you should always check the generated assembly to ensure your tuning is having the desired effect.

Epilogue

If you’ve never heard of the Compiler Explorer, aka, godbolt.org, it’s an extremly useful in-browser tool for compiling C or C++ code with virtually any compiler you’ve ever heard of, at any optimization level, and showing you a mapping from source lines to their corresponding assembly lines for most any CPU architecture. (Why is it called godbolt? Because its creator is Matt Godbolt.)

Technical Writing Advice

Paul J. Lucas — Thu, 18 Jun 2026 14:00:30 +0000

Introduction

I’ve occasionally thought about writing about how to write (and how not to write) technical material. Recently, someone e-mailed me asking for advice about doing just that. So this article is a collection of my previous thoughts about this as well as a distillation of how I replied to that e-mail.

Any kind of writing, like many other human endeavors, is a combination of talent and skill. For talent, you’ve either got it or you don’t; whereas skill can be learned, improved, and mastered. It’s generally difficult even to explain talent because it’s largely unconscious. I can’t tell you how the amorphous ideas in my head get converted to words on a page or screen — it just happens; however, I can tell you some things to do (and not do).

There are many kinds of technical material. I’ve mostly written articles, journal papers, Unix-style manual pages, API documentation, and a couple of books, so my advice is relevant only for those.

I largely consider the following advice to be obvious, so I don’t think it should be necessary; but I’ve seen lots of bad technical writing, so I guess the advice is apparently necessary after all.

The advice can be distilled into the following points. Your writing should be:

Different.
Well-formatted.
Right.
Precise.
Complete.
Consistent.

Also note that this advice is from the perspective of doing your own technical writing, i.e., writing about what you want to write about. If you’re a technical writer by trade, then your day job is writing about what other people want you to write about. You’re also most likely constrained by an in-house style guide. My advice isn’t for you.

Different

Before actually writing anything, you should first determine whether what you want to write about is worth writing at all. Does the world really need yet another introduction to basic data types like int and char in C?

However, if you’re going to go really deep into or show some obscure thing about or a creative use of a topic, i.e., something different, then by all means go ahead.

Formatting

To me, it should be obvious that what you write should be well-formatted — yet I’ve seen so many examples of badly formatted writing. When badly formatted, reading becomes visually jarring and a chore to slog through. I don’t even understand how anyone can publish anything that’s badly formatted. Don’t they look at it and think, “This looks terrible!”? (I suspect there’s a gene for having an aesthetic sense and some people don’t have it.)

In contrast, in well-formatted writing, the formatting just fades into the background so that you don’t even notice it and reading becomes easy.

For technical writing involving code, the code should be in a different typeface, generally monospaced, and typically Courier.

“Typeface” is the correct term. A typeface is a style of letters and symbols; a font is a typeface in a particular size (e.g., 10 point) and style (e.g., bold). Courier, Helvetica, and Times Roman are typefaces; Helvetica 10 Bold is a font.

I blame Apple for everyone’s mis-use of font to mean typeface. Originally, the Lisa used Type Style for the name of what is now the Font menu in most GUI applications. But then for some reason, the Mac changed the menu name to Font and the mis-use ensued.

If what you write is badly formatted, the rest pretty much doesn’t matter since nobody is going to want to read it anyway.

Some things that form part of my (and others’) styles include:

Use inline or footnotes for incidental information or to cite sources. (Alternatively, you can use brackets like [42] or [Lucas, 1992] to cite sources with a References section.)
Use parentheses for clarifying information or an aside that isn’t big enough to warrant either an inline or footnote.
Use italics for one of emphasis, for the first occurrence of an important term, or the title of another work.
Use quotes for one of literal text, a definition, a colloquial term, or a metaphor.

For example that illustrates most of the above, here’s an excerpt from Why Learn C, §1.1, p. 3:

C program source files conventionally end with a “.c” extension, so, assuming this program is in a file hello.c, it must be compiled (converted from source code into an executable) with a C compiler. On most Unix systems, the C compiler is named “cc” (short for “C compiler”).

Be Right

It should also be obvious that what you write should be right — yet I’ve seen so many examples of what someone has written is flat out wrong. Even if you think you know something well, double check before you write about it.

Be Precise

While I think all writing should be precise, technical writing especially needs to be precise. Some examples:

Parameters and arguments are different things.
If something must be true, then use “must.” (See also RFC 2119.)
Use “only if” whenever possible.

For an example of “only if,” consider:

The standard library function isprint returns true if a character is “printable,” that is one of a space, a punctuation symbol, a letter, or a digit.

The problem with just using “if” is that it incorrectly leaves open the possibility that isprint returns true in other cases as well. Replacing “if” with “only if” correctly eliminates that possibility. As a rule of thumb, any time you use “if” in a sentence, try replacing it with “only if”: if the sentence still sounds right and is more correct, then use “only if.”

Be Complete

Don’t write something that’s either only partly true or mostly true. The situation you want to avoid is a reader reading something you’ve written and thinking that’s all there is to the topic.

Yes, I understand that you may not want to wade deep into the weeds in an introduction for a topic. If that’s the case, at least mention that there’s more to a topic that you’ll get to later or can safely be ignored for now. For example, Why Learn C, §1.5, p. 14, contains the sentence:

Before continuing the tour, we need to digress on computer memory. It’s basically a (very long) sequence of bytes, each having a unique integer address.

While that’s true, it’s only mostly true; but then it’s followed by the inline note:

■ This is an oversimplification due to both register and cache memory, but those can be safely ignored for now. □

Be Consistent

Be consistent about word choices and term use. For example, if you use “error code,” don’t later write “status code.” Readers may wonder if they’re the same thing.

A Note on AI

Don’t use AI to do the majority (or all) of your writing, certainly don’t copy & paste verbatim from it. Sometimes I use AI like a thesaurus to suggest alternate words or terms, but that’s pretty much it for me.

If you’re writing but not fluent in a language that is not your native language, you can be forgiven for using AI a bit more, e.g., copying something you’ve written into an AI and asking it for advice. Still, don’t copy its suggestions verbatim: edit them to fit into the rest of your writing style.

Things to Not Do

Here’s a non-exhaustive list of things that, when I see them, don’t give me confidence that the rest of what I’m about to read will be worth my time.

Unless you’re writing a personal account of something or giving a personal opinion, don’t write in first-person (“I ...”).
Don’t include gratuitous images. Include images only that illustrate what you’re trying to explain. Gratuitous images are distracting. Even worse are animated images. You don’t want what you write to look gaudy.

For titles:

Don’t use numbers of things (unless there’s some importance to the numbers).
Don’t use hyperbole.
Don’t use click-bait wording.

It makes your writing sound juvenile. Here’s an actual bad example I recently found online:

7 Coding Patterns I Stole From Senior Engineers

Who cares if it’s seven? Or five? Or ten? “Stole?” It’s called learning from — presumably from open source that’s, well, open and free to learn and copy from. Better:

Coding Patterns Used by Senior Engineers

Or something like that.

Conclusion

To adapt a some advice one of my mentors gave to me once: do you want people to remember your writing for the way it looked or for what it said?

If you want to be taken seriously, then write as if you were submitting your writing to a prestigious journal or publisher. Some day, you might want to.

Clifford’s (aka, Claire’s) Device in C and C++

Paul J. Lucas — Wed, 10 Jun 2026 23:29:18 +0000

Introduction

If you’ve been programming in C or C++ for a while, you likely have heard of Duff’s Device that takes advantage of C’s often-derided “feature” where case blocks “fall through” into the next case (if any).

Regardless of what you think of that, I only recently discovered that there’s another “device” known as Clifford’s Device (alternatively known as Claire’s Device). While the problem it solves is completely different from Duff’s, it uses another of C’s quirks.

Preamble

Sometimes you have a block of code that you want to delete temporarily, but don’t want to delete it permanently just in case you might need it again in the future.

If you’re using a VCS like git, of course you can delete the code because it’ll be preserved in the history, but, if you want the code back, you have to find the commit that deleted it and revert the commit. If the commit did more than simply delete the relevant code, then it gets harder.

As an alternative, you can use the preprocessor to disable a block of code:

#if 0
  // ... disabled block of code ...
#endif

As another alternative, you can instead do:

if (0) {
  // ... disabled block of code ...
}

Since 0 is always false, the code, though compiled, will never be executed. (The optimizer might even optimize the code away entirely.)

The Device

The device also uses if (0) and is trivial: you simply include a label that’s the target of a goto.

  if (0) {
label:
    // ... code ...
  }

That’s it. What use is that? It allows a block of code to be executed only if explicitly gotod. Code before it won’t simply “fall into” it. The code also resumes the normal code flow.

We can rewrite the missing_arg example from the goto post to use the device:

void cli_options_init( int *pargc, char const **pargv[] ) {
  // ...
  for (;;) {
      // ...
      if ( option->has_arg == required_argument ) {
        if ( optarg == NULL )
          goto missing_arg;
        SKIP_WS( optarg );
        if ( optarg[0] == '\0' )
          goto missing_arg;
      }
      // ...

    switch ( opt ) {
      // ...
      case ':':
        goto missing_arg;
    }
  }
  // ...
  //return;   // This return is no longer needed

  if (0) {
missing_arg:
    fatal_error( EX_USAGE,
      "\"%s\" requires an argument\n",
      get_opt_format( opt == ':' ? optopt : opt )
    );
  }
}

Macros

While the device works as-is, it’s a bit ugly. As it often the case, we can use a preprocessor macro to hide the ugliness:

#define only_if(LABEL)   if (0) LABEL:

Then:

  only_if ( missing_arg ) {
    fatal_error( EX_USAGE,
      "\"%s\" requires an argument\n",
      get_opt_format( opt == ':' ? optopt : opt )
    );
  }

The “only if” means that the code will be executed only if an option is missing its required argument.

Notice that the position of the label is now before the {. It’s completely equivalent because a compound statement of { ... } is a statement and C allows you to put a label before any statement.

You could even take macros a step further and simulate exception handling in C:

#define try           if (1)
#define throw         goto
#define catch(LABEL)  if (0) LABEL:

void cli_options_init( int *pargc, char const **pargv[] ) {
  // ...
  try {
      // ...
      if ( option->has_arg == required_argument ) {
        if ( optarg == NULL )
          throw missing_arg;
        SKIP_WS( optarg );
        if ( optarg[0] == '\0' )
          throw missing_arg;
      }
      // ...
  }
  catch ( missing_arg ) {
    fatal_error( EX_USAGE,
      "\"%s\" requires an argument\n",
      get_opt_format( opt == ':' ? optopt : opt )
    );
  }
}

Of course this is a false facade since this “exception handling” works only within the same function unlike real exception handling where an exception can be caught in any calling function.

Should you actually do this in production code? Probably not. I only wanted to show that the device can be used in a “clever” (revolting?) way for curiosity. Besides, there is a better way to do exception handling in C. In C++, you have real exception handling, of course.

`switch`

You can also use the device in switch statements just like Duff’s:

switch ( c ) {
  only_if ( case '\0' ) {
    // ...
  }
  only_if ( case '=' ) {
    // ...
  }
  only_if ( default ) {
    // ...
  }
}

Doing so allows you to eliminate the breaks between cases. This works because a case or default label is a label syntactically.

Should you actually do this in production code? Probably not. Even if you dislike that C “falls through” into the next case, code using such a macro is likely more confusing for the uninitiated than C’s normal and well-known behavior. I only wanted to show that the device can be used in a switch for curiosity.

Conclusion

Clifford’s (or Claire’s) Device is another quirky “feature” of C in that you can goto into a compound statement at any point. It has a marginal use when used with a goto; less so with switch.

Use wisely.

goto in C and C++

Paul J. Lucas — Mon, 08 Jun 2026 17:48:01 +0000

Introduction

Both C and C++ include the goto statement that goes (jumps) to the statement having the given label within the same function, for example:

  if ( disaster )
    goto error;
  // ...

error:
  // handle the error

As you probably know, goto has a bad reputation stemming chiefly from Edsger Dijkstra’s infamous go to Statement Considered Harmful (1968) letter wherein he wrote in part:

For a number of years I have been familiar with the observation that the quality of programmers is a decreasing function of the density of go to statements in the programs they produce. More recently I discovered why the use of the go to statement has such disastrous effects, and I became convinced that the go to statement should be abolished from all “higher level” programming languages ….

Notice that he says the quality of programmers, not programs, decreases the denser the use of goto is; hence not only are programs with lots of gotos bad programs, but if you’re the author of such a program, you’re a bad programmer.

Not only was Dijkstra’s letter extremely influential, but its title has spurred an entire considered harmful template for other essays and papers including “Considered Harmful” Essays Considered Harmful.

As a curious historical note, Dijkstra’s original title was “A Case Against the Goto Statement,” but it was Niklaus Wirth, the then-editor of CACM, that changed the title. We’ll never know if Dijkstra’s letter would have had the same degree of influence had it kept its original title, but probably.

For a detailed analysis of Dijkstra’s letter, see Dijkstra’s Letter, Annotated.

What led to Dijkstra writing his letter was the (over)use of goto in programs written in either early versions of Fortran (1957–1966) and BASIC (1964–). To be fair, those programming languages had no other way to jump elsewhere in a program which is in part what led to increased support for the structured programming movement. (The term “structured programming” was coined by Dijkstra.)

Even Kernighan and Ritchie in their also extremely influential The C Programming Language wrote in part (1st ed., §3.9, pp. 62–63):

C provides the infinitely-abusable goto statement, and labels to branch to. Formally, the goto is never necessary, and in practice it is almost always easy to write code without it. We have not used goto in this book. Nonetheless, we will suggest a few situations where gotos may find a place.

Those few situations are what this post is about.

Legitimate Uses

Aborting Processing

One legitimate use for goto was shown at the outset of this post, namely error handling, but where either clean-up code is necessary, such as freeing memory, closing files, or unlocking mutexes, or simply printing the same error message. The legitimacy increases with the number of gotos going to the same label.

For example, this code from my include-tidy project contains:

void cli_options_init( int *pargc, char const **pargv[] ) {
  // ...
  for (;;) {
      // ...
      if ( option->has_arg == required_argument ) {
        if ( optarg == NULL )
          goto missing_arg;
        SKIP_WS( optarg );
        if ( optarg[0] == '\0' )
          goto missing_arg;
      }
      // ...

    switch ( opt ) {
      // ...
      case ':':
        goto missing_arg;
    }
  }
  // ...
  return;

missing_arg:
  fatal_error( EX_USAGE,
    "\"%s\" requires an argument\n",
    get_opt_format( opt == ':' ? optopt : opt )
  );
}

While it is possible to eliminate the uses of goto here, doing so would require either much more deeply nested if statements or the introduction of flags, both of which would make the code harder to understand.

For a case where you have to do specific clean-up, such as calling free, a defer statement like the one found in Go would be better if it were added to C:

void read_file( FILE *file );
  void *const buf = malloc( BUF_SIZE );
  defer free( buf );  // hypothetical defer in C
  // ...
}

Then, no matter^* how you return from the function, free will be called.

There actually is a proposal to add defer to C. Currently, it’s slated to be added to C29, the next standard version of C.

* Well, there are cases where it does matter, but that would be going too far into the weeds on defer that this post isn’t about. For such details, read the proposal.

In C++, there are destructors, so this use for goto is largely eliminated.

Nested Loop or `switch` Statements

While both C and C++ contain the break and continue statements, break breaks out of only the most lexically enclosing loop (while, do, or for) or switch; continue continues only the most lexically enclosing loop. There’s also this article that’s good.

In some cases, however, you want either to break or continue the not most lexically enclosing loop or switch. Unlike in either Java or Rust, in C or C++, you can only use a goto. The example already given above is also an example for this case.

There is also a proposal to add named loops to C such that you could do something like:

loop:
for ( int i = 0; i < j; ++i ) {
  switch ( n ) {
    // ...
    case 99:
      break loop;  // hypothetical named loop
  }
}

That is, a label in front of a loop can be referenced by a break or continue in addition to goto. Currently, it too is slated to be added to C29.

Restrictions

Prior to C23, a label could not be attached to a declaration (because a declaration is not a statement in C; it is in C++):

  if ( disaster )
    goto error;
  // ...
error:           // illegal < C23; OK in C23 or C++
  int err_code;

The common work-around is to insert a null statement, i.e., a single semicolon:

error:;          // note ';' -- OK in all C versions
  int err_code;

All C versions forbid jumping past the declaration of a “variably modified type,” i.e., variable length arrays (VLAs) or pointers to such:

void f( unsigned n ) {
  // ...
  goto skip;     // error: can't skip past ...
  // ...
  int a[n];      // ... VLA
  int (*p)[n];   // ... or pointer to VLA

skip:
  // ...
}

C++ has more restrictions than C regarding use of goto, specifically that you can’t jump past a declaration if its type has a “non-trivial constructor” or has an initializer:

  goto skip;
  // ...
  int x;          // OK: no initializer
  std::string s;  // error: has non-trivial constructor
  int y = 42;     // error: has initializer
  // ...
skip:
  // ...

Advice

Here’s some advice for using (or not using) goto:

Of course prefer break, continue, return, or any loop when those do exactly what you want.
If you would need to add one of multiple flags, multiple tests, or more deeply nested code, consider a goto instead.
Personally, I think it’s a good practice only to go to a line that’s later in a function rather than earlier, either immediately after a loop or at the end of a function. If you want to go earlier, it likely means you’re looping, so use an actual loop instead.
Put clean-up code that’s the target of a goto at the end of a function where it more clearly stands out.

Conclusion

I think Dijkstra’s wish to abolish goto entirely goes a bit far. Certainly, you want to avoid either inappropriate or over-use of gotos lest you end up with spaghetti code. While a lot of code can (and should) be written easily without goto, a justified use of an occasional one won’t make you a bad programmer.

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 ia;
array_init( &ia, 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 void* 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 < ia.len; ++i ) {
  int n = *(int*)array_at_nc( &ia, 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( &ia ) = 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) ia;

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) ia;
typed_array_init( &ia );
*typed_array_push_back( &ia ) = 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.

DEV Community: Paul J. Lucas

Program Organization (with Examples in C)

Introduction

Components

Program-Specific Data Structures and Algorithms

Generic Data Structures and Algorithms

Program Options

Command-Line Parsing

Configuration File Parsing

Program-Specific Utilities

Generic Utilities

Conclusion

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

Introduction

Why IWYU for C++ is Harder

Nested Types and Inheritance

Functions and Derived Arguments

Nested Types and Aliases

Conclusion

Into the void

Introduction

History

Function Prototypes

Pointers

Casting

Conclusion

A Generic min Function in C

Introduction

Functions

_Generic

Conclusion

Another Tale of Two Threads (C or C++ vs. Python)

Introduction

Background

Threads in C and C++

Threads in Python

Conclusion

Pointers and Tuning and Loops! Oh My!

Introduction

Loop Refresher

Pointers

restrict Revisited

Explicit Caching

Conclusion

Epilogue

Technical Writing Advice

Introduction

Different

Formatting

Be Right

Be Precise

Be Complete

Be Consistent

A Note on AI

Things to Not Do

Conclusion

Clifford’s (aka, Claire’s) Device in C and C++

Introduction

Preamble

The Device

Macros

switch

Conclusion

goto in C and C++

Introduction

Legitimate Uses

Aborting Processing

Nested Loop or switch Statements

Restrictions

Advice

Conclusion

A Simple Dynamic Array for C

Introduction

A Simple Dynamic Array

Initialization & Clean-Up

Accessing Elements

Appending Elements

Other Functions

Adding Type Information

Caveat

`_Generic`

`restrict` Revisited

`switch`

Nested Loop or `switch` Statements

`const`

`constexpr`