Some Obscure C Features

In numerical analysis, "Hexadecimal float with an exponent" is not an obscure feature, it's a really nice one! If you want to communicate to somebody an exact number that your program has output, you need to either tell them the decimal number to enough digits + the number of digits (i.e., "Float32(0.1)", which is distinct from "Float64(0.1)"), or you can tell them the same number in full precision in binary, in which case the floating-point standard guarantees that that number is exactly correct and does not depend on how you interpret it. It's really nice for testing numerical code, especially with automated reproducible tests. Completely unambiguous, and I wish more languages had that (I saw the feature in Julia first).

The preprocessor trick of passing function macros as parameters is not that obscure. I have seen it used and I've used it myself. It is very useful when you have a list of static "things" that you need to operate on.

Say I have a static list of names and I would like to declare some struct type for each name. I also would like to create variables of these structs at some point, and I would always do so for the entire block of names. You could do something like this:

    #define apply(fn) \
        fn(name1) \
        fn(name2) \
        fn(name3) \
        ...
        fn(nameN)

    #define make_struct(name) struct name##_t { ... }
    #define make_variable_of(name) name##_t name;
    
    ...

    apply(make_struct);  // This defines all the structs.
 
    void some_function(...) {
        apply(make_variable_of);  // And this defines one variable of each type.
    }

Yes, it is not pretty (it is the C preprocessor after all), but it can be very useful and clean.

Most of these are due to the cruft added in C99 and later.

Compile-time trees are possible without compound literals.

More than twenty years ago, I made a hyper-linked help screen system a GUI app whose content was all statically declared C structures with pointers to each other.

At file scope, you can make circular structures, thanks to tentative definitions, which can forward-declare the existence of a name, whose initializer can be given later.

Here is a compile-time circular list

   struct foo { struct foo *prev, *next; };

   struct foo n1, n2; /* C90 "tentative definition" */

   struct foo circ_head = { &n2, &n1 };

   struct foo n1 = { &circ_head, &n2 };

   struct foo n2 = { &n2, &circ_head };

You can't do this purely declaratively in a block scope, because the tentative definition mechanism is lacking.

About macros used for include headers, those can be evil. A few years ago I had this:

   #include ALLOCA_H  /* config system decides header name */

Broke on Musl. Why? ALLOCA_H expanded to <alloca.h>. But unlike a hard-coded #include <alloca.h>, this <alloca.h> is just a token sequence that is itself scanned for more macro replacements: it consists of the tokens {<}{alloca}{.}{h}{>}. The <stdlib.h> on Musl defines an alloca macro (an object-like one, not function-like such as #define alloca __builtin_alloca), and that got replaced inside <alloca.h>, resulting in a garbage header name.

I was reading the source code for a NES assembler written in pre-C99 C, and there was an odd C feature used in it that I haven't really seen anywhere else.

It was before C had built-in booleans and the author had defined their own, but true was:

    void * true_ptr  = &true_ptr;

true_ptr is a pointer to itself. So however many times you deference it:

    printf("%p\n", true_ptr);
    printf("%p\n", &true_ptr);
    printf("%p\n", *((void**)true_ptr));
    printf("%p\n", *((void**)*((void**)true_ptr)));

You get the same pointer:

    0x5555fefe715b
    0x5555fefe715b
    0x5555fefe715b
    0x5555fefe715b

I still think that it's neat that, even with ASLR, you have an address at compile time that you know won't collide with address space of malloc results, or the address space of your stack.

Also you can declare the pointer as const and the value it points to as const and, if your kernel faults on writing to readonly memory pages, you get a buggier version of a NULL pointer that only segfaults on write.

Also it takes a second to figure out why the position of the const matters even though the pointer's value is the value of the pointer, and why only one of these segfaults on write:

    const void * const_pointer = &const_pointer;
    void * const const_value   = &const_value;

No mention of trigraphs? They are one of my favourite obscure C language features that I've never used.

Excerpt from GCC man page:

  Trigraph:       ??(  ??)  ??<  ??>  ??=  ??/  ??'  ??!  ??-
  Replacement:      [    ]    {    }    #    \    ^    |    ~

Missing backslash on your keyboard? No problem, just type ??/ instead.

A more obscure feature is the uncommon usage of comma operator. We often use the comma operator in variable declaration and in for loops. But it can also be used in any expression.

For instance, the next line has a valid C construct:

   return a, b, c;

This is particularly useful for setting variable when retuning after an error.

   if (ret = io(x))
       return errno = 10, -1;

The possibilities are endless. Another example:

    if (x = 1, y = 2, x < 3)
     ...

But the comma operator really shines when used in conjunction with macros.

All craziness but then:

>a[b] is literally equivalent to *(a + b).

Is this obscure? I thought that's pretty much the first thing you learn about arrays in C? It's pointers, all the way down.

These examples actually were more obscure than the usual list.

A little off-topic but here is a cool piece of code about a special case in C:

    void (*foo)() = 0;
    void (*bar)() = (void *)0;
    void (*baz)() = (void *)(void *)0; // Error

Can you guess why compilers reject the last line?

Although calling the preprocessor "functional" is being too pleasant. The C preprocessor was always a text substitution system, so macro as parameter is not that "obscure". Of course, I may have missed something subtle in the example.

It's also not clear how to use that preprocessor example.

sizeof actually doesn't evaluate its expression for side effects most of the time; only if the operand is a variable-length array is it evaluated.

The article has examples of array parameters like

    int b[const 42][24][*]

but you can get more fun with variably modified array parameters instead of just constants like 42. For example,

    double sum_a_weird_shaped_matrix(int n, double array[n][3*n]) {
        double total = 0;
        for (int x = 0; x < n; ++x) {
            for (int y = 0; y < 3 * n; ++y) {
                total += array[x][y];
            }
        }
        return total;
    }

has a variable and a more complicated expression in those positions.

But those variably modified parameters can have arbitrary expressions in them, like

    int last(size_t len, int array[restrict static (printf("getting the last element of an array of %zu ints\n", len), len--)]) {
        return array[len];
    }

C++ denies us this particular joy which could have made function overload resolution even more fun.

A nice but I guess more of a linker feature is if you declare a function as __weak__, you can check it at runtime for == NULL to determine if the application was built with the function defined.

One of the more obscure, yet often employed, "features" is to use something else as a C preprocessor.

This was c++ and not C, but it is a preprocessor pitfall.

I needed to compare and older and newer version of some file from the RCS, so I saved temporary copies named "new" and "old". diff told me what I needed to know, but I failed to delete those temp files.

Hours later I typed "make" to build my program and got all sorts of errors deeply nested in some library function. Did someone misconfigure the server I was on? OK, maybe it is an incremental build problem? etc. It took took long to figure out the problem.

It turns out that during compilation, as one of the library .h files was being scanned, it contained #include <new>, which picked up the junk file in my working directory instead of using the C library.

I found the most interesting one to be compile time trees.

Does anyone have any good use cases for it?

Effectful sizeof, what a delightful feature!

Though the compile-time magic with structs and functional macros are so tempting that I feel like it's high time to do some C.

> VLA typedef ... I have no clue how this could ever be useful.

I used this feature recently. I had several arrays of the same size and type, and the size was determined at runtime. The VLA typedef let me avoid duplicate type signatures which I find more readable.

    int N = atoi(argv[1]);
    typedef int grid[N][N];
    grid board;
    grid best;
    grid cache;

No mention of the downto (-->) operator?

  int x = 10;
  while (x --> 0) {
    printf("%d ", x);
  }

> a[b] is literally equivalent to *(a + b). You can thus write some absolute madness such as 41[yourarray + 1].

Wow. This has to be the best C obscurity that I've ever seen.

The WTF part seems useful. E.g.

type quaternion float[4];

quaternion SLERP = {1.0, 0, 0, 0};

Hell, c11 has ghetto generics.

Are we calling these features, now?

Here is an obscure c feature:

  int main()
  {
     int a = 8;
     {
       int a = 4;
       /* a is only scoped to this block */
     }
     printf("%d", a); /* prints 8 */
  }

It is also why C++ is not a strict superset of C