Forem: Yair Lenga

Automatic Enum Handling in C — Parsing, Validating and Iterating.

Yair Lenga — Mon, 04 May 2026 15:06:46 +0000

In a previous post, Automatic Enum Stringification in C via Build-Time Code Generation, I described how to extract enum labels and values directly from DWARF debug information at build time.

enum color { C_NONE, C_RED, C_YELLOW, C_GREEN } ;

// Request enum descriptor for e_color
ENUM_DESCRIBE(e_color, enum color)
void foo(enum color c) {
    printf("Color=%s(%d)\n", ENUM_LABEL_OF(e_color, c), c) ; 
}

In a follow-up article, I wrote about the next logical step: reverse conversion from symbolic name to value. This is useful when reading external input keyed by enum values: command-line arguments, configuration files, or user input.

ENUM_DESCRIBE(e_color, enum color)

bool parse_color(const char *label, enum color *var)
{
    return ENUM_PARSE_LABEL(e_color, label, var) ;
}

Medium Article (No Paywall): Automatic Enum Handling in C — Parsing, Validating and Iterating.

Beyond simple conversion label -> value, the collected metadata can be used to iterate over all enum values. This enables more advanced matching (e.g., partial or best match), or integration with external data keyed by enum values.

In some cases, it can be useful to have the enum metadata available outside the C program. The extraction script can produce the information in TOML format - which can be read directly into Python or Java.

[enum.currency]
_.count = 154
_.symbol = "enum_req_currency"
_.anchor = "enum_type_currency"
_.name = "currency_code"
_.byte_size = 4

ISO3_AED = 784
ISO3_AFN = 971
ISO3_ALL = 8
ISO3_AMD = 51
ISO3_ANG = 532
ISO3_AOA = 973
ISO3_ARS = 32
ISO3_AUD = 36

Until C has reflection, extracting the enum label/value pairs from the debug section can provide an effective way to use this information in C programs. This gives you reflection-like capabilities in plain C — without changing your source code.

No changes to existing enum definitions in the source code.
No duplicate definitions.
No runtime dependency on external tools or libraries.
Always in sync with the compiled enum.

A compact package (~20KB) (one ".c" file, one ".h" file, and Python script to extract debug information from object files) is available here:

https://github.com/yairlenga/c-enum-reflect/releases/latest

See the Releases page for other versions and packages.

Automatic Enum Stringification in C via Build-Time Code Generation

Yair Lenga — Mon, 27 Apr 2026 11:00:00 +0000

The C compilers (gcc, clang, ...) capture lot of information about the code and store in the information as debug information. Sometimes, we can leverage this information and enhance our code with minimal effort.

I wrote about automatic enum stringifcation in C, using build-time code generation from DWARF debug info.

No manual lookup tables to build or maintain, no complex macros - just compile, extract and link.

The final binary contains plain C data structures with zero runtime dependency on DWARF libraries, or tools.

enum country_code {
    ISO3_AFG = 4,    /* Afghanistan */
    ISO3_ALB = 8,    /* Albania */
    ISO3_ATA = 10,   /* Antarctica */
    ISO3_DZA = 12,   /* Algeria */
    ...
} ;

ENUM_DESCRIBE(country3, country_code)

void foo(enum country_code c)
{
    printf("Called with C=%s\n", ENUM_LABEL_OF(country3, c)) ;
}

Medium Article (No Paywall): Automatic Enum Stringification in C via Build-Time Code Generation

The process work in 4 steps:

The C code that uses the enum is complied with debug mode (-g)
A python program extract the enum definition from the object files, and generate the meta data that is needed to support the reflection as C code.
The generated C code is compiled and linked into the final binary.
At run time, the program read the meta data and and can complete the conversion with no additional dependencies.

Curious about what other techniques are used to solve similar problem.

Optimizing Chained strcmp Calls for Speed and Clarity

Yair Lenga — Tue, 14 Apr 2026 10:35:42 +0000

From memcmp and bloom filters to 4CC encoding for small fixed-length string comparisons

I've been working on an article to describe a small performance issues with a pattern I've seen multiple times - long chain of if statements based on strcmp. This is the equivalent of switch/case on string value (which is not supported in C).

The code implemented critical business logic, based on currency codes (ISO 3-letter code), and an as-of date. Similar to:

bool model_ccy_lookup(const char *s, int asof, struct model_param *param)
{
    // Major Currencies
    if ( strcmp(s, "USD") == 0 || strcmp(s, "EUR") == 0 || ...) {
        ...
    // Asia-Core
    } else if ( strcmp(s, "CNY") == 0 || strcmp(s, "HKD") == 0 || ... ) {
        ...
    } else if ( ... ) {
        ...
    } else {
        ...
    }
}

The code couldn’t be refactored into a different structure (for non-technical reasons), so I had to explore few approaches to keep the existing structure - without rewrite/reshape of the logic. I tried few tings - like memcmp, small filters, and eventually packing the strings into 32-bit values (“4CC”-style) and letting the compiler work with integer compares.

I was able to revise the code into cleaner form, which outperform the original code by 10X. This was achieved with a series of experiments, some of them helped, some of them did not yield improvements, but hinted at other directions.

Full Article: Medium (No Paywall):

Optimizing Chained `strcmp`Calls for Speed and Clarity

The final implementation looks like:

bool model_ccy_lookup(const char *s, int asof, struct model_param *param)
{
    // Major Currencies
    if ( CCY_IN(s, "USD", "EUR", ...) ) {
        ...
    // Asia-Core
    } else if ( CCY_IN(s, "CNY", "HKD", ...) ) {
        ...
    } else if ( ... ) {
        ...
    } else {
        ...
    }
}

And the CCY_IN was implemented as a series of integer compare, using the FourCC encoding = replacing each fixed-size strcmp with a call to CCY_EQ macro:

#define CCY_EQ(x, ccy) (*(int *)x == *(int*) ccy )

I’m also trying a slightly different writing style than usual - a bit more narrative, focusing on the path (including the dead ends), not just the final result.

If you have a few minutes, I’d really appreciate feedback (comment here or on Medium) on two things:

Does the technical content hold up?
Is the presentation clear, or does it feel too long / indirect?

Interested to hear on other ideas/approach for this problem as well.

Safer Casting in C — With Zero Runtime Cost

Yair Lenga — Tue, 07 Apr 2026 07:58:10 +0000

C gives us two types of casting: Implicit casting — happens automatically in expressions and function calls, and Explicit casting — with the cast operator (T) v (e.g. (int) x).

Both are powerful - and both introduce risks - making subtle, hard-to-detect bugs easy to introduce.

I've been looking for safer way to use casts in C, and I came up with simple idea: replace (T) v with function like macros, similar in spirit to SQL's CONVERT(type, value).

A Small Example (same behavior, better readability):

// before, It it:
//     (*((long *) buf)) + 1 OR
//     *((long *) (buf + 1 )) OR
//     *(((long *) buf) + 1)
long p = *(long *) buf + 1;

/* after */
long p = *CAST_PTR1(long *, buf) + 1;

Full Article (Medium - no paywall):

Safer Casting in C — With Zero Runtime Cost

I tried a simple approach: replace (T)v with function-like macros such as CAST_VAL, CAST_PTR, and CAST_PTR1, and UNCONST. The idea isn’t to make C type-safe, but to make casts explicit, structured, and easier to audit. Some basic checks can be enforced at compile time (using gcc/clang extensions), and everything still compiles down to the same code — no runtime cost.

In practice, this shifts casts from “hidden syntax” to something more visible and intentional. For example, separating value casts from pointer casts, and explicitly handling things like removing const, makes questionable conversions stand out immediately in code review.

Curious if others have tried something similar, or if you rely mostly on compiler warnings (-Wconversion, -Wcast-*) and static analysis for this. Does this feel useful, or just adding noise on top of C’s existing model?

Stack vs malloc: real-world benchmark shows 2–6x difference

Yair Lenga — Wed, 01 Apr 2026 12:02:40 +0000

Usually, we assume that malloc is fast—and in most cases it is.
However, sometimes "reasonable" code can lead to very unreasonable performance.

In a previous post, I looked at using stack-based allocation (VLA / fixed-size) for temporary data, and another on estimating available stack space to use it safely.

This time I wanted to measure the actual impact in a realistic workload.

Full Article (Medium - no paywall):

Stack vs malloc: real-world benchmark shows 2–6x difference

I built a benchmark based on a loan portfolio PV calculation, where each loan creates several temporary arrays (thousands of elements each). This is fairly typical code-clean, modular, nothing unusual.

I compared:

stack allocation (VLA)
heap per-loan (malloc/free)
heap reuse
static (baseline)

Results:

stack allocation stays very close to optimal
heap per-loan can be ~2.5x slower (glibc) and up to ~6x slower (musl)
even optimized allocators show pattern-dependent behavior

The main takeaway for me: allocation cost is usually hidden—but once it's in the hot path, it really matters.

Curious how others approach temporary workspace in performance-sensitive code.

Avoiding malloc for Small Strings in C With Variable Length Arrays (VLAs)

Yair Lenga — Thu, 19 Mar 2026 13:31:00 +0000

Many C programs allocate small temporary buffers using malloc(), even when the buffer only lives for the duration of a function call.

In many cases, stack allocation using VLAs can be significantly faster because it avoids allocator overhead and improves cache locality.

I wrote a deeper analysis including benchmarks and practical guidelines.

Full article (Medium — no paywall):
Using VLA for Faster Temporary Strings in C

The article proposes conditional logic: use a VLA when the requested size safely fits on the stack, and fall back to malloc() otherwise. Small macros hide the decision so the code remains compact and readable.

static void test1(bool show, const char *s1, const char *s2)
{
  // Create char *result - pointing to heap/stack
  FLEX_STR_INIT(result, strlen(s1) + strlen(s2) + 1);

  // Use the buffer
  concat(FLEX_STR_BUF(result), s1, s2)) ;
  printf("result(%zu)=%s\n", FLEX_STR_SIZE(result), result);

  // Release buffer (NOOP is VLA was used)
  FLEX_STR_FREE(result);
}

For small strings this approach can reduce allocation overhead dramatically.

Estimating Remaining Stack Space in a C Program

Yair Lenga — Tue, 17 Mar 2026 23:40:13 +0000

Many programmers believe there is no reliable way to know how much stack space remains in a running C program. Because of this uncertainty, stack allocation techniques such as VLAs or alloca() are often considered unsafe unless the buffer size is extremely small.

On modern Unix systems (Linux, BSD, macOS), the runtime environment actually exposes enough information to estimate the remaining stack space with reasonable accuracy. By combining stack limits with the current stack pointer, it is possible to determine how much space remains before reaching the guard page.

I wrote a detailed explanation, including example code and a small utility function that estimates available stack space.

Full article (Medium, NO paywall):
How Much Stack Space Do You Have? Estimating Remaining Stack in C on Linux

The article discuss 3 techniques:

getrlimit()
pthread_getattr_np()
GCC/CLANG constructor attribute.

Together these allow building a small helper API such as:

size_t stack_remaining(void)
{
    StackAddr sp = stack_marker_addr() ;
    if ( sp < stack_low_mark ) stack_low_mark = sp ;
    return sp - stack_base - safety_margin;    
}

This allows programs to inspect available stack space at runtime and make better decisions when choosing between stack allocation and heap allocation.

Have you ever needed to estimate stack usage in production code?

Forem: Yair Lenga

Automatic Enum Handling in C — Parsing, Validating and Iterating.

Automatic Enum Stringification in C via Build-Time Code Generation

Optimizing Chained strcmp Calls for Speed and Clarity

From memcmp and bloom filters to 4CC encoding for small fixed-length string comparisons

Full Article: Medium (No Paywall):

Optimizing Chained strcmpCalls for Speed and Clarity

Safer Casting in C — With Zero Runtime Cost

Full Article (Medium - no paywall):

Stack vs malloc: real-world benchmark shows 2–6x difference

Full Article (Medium - no paywall):

Avoiding malloc for Small Strings in C With Variable Length Arrays (VLAs)

Estimating Remaining Stack Space in a C Program

Optimizing Chained `strcmp`Calls for Speed and Clarity