Clockwise/Spiral Rule (c-faq.com)

I always found this to be one of C's (and it's descendants) more ridiculous aspects.

You should not need an entire algorithm just to mentally parse a declaration. The rules should be sufficiently straight forward so that the advanced pattern matching in our brains should suffice.

It is excusable since C is old, but ridiculous nonetheless.

    const char *str;

    const char *strs[4];

    const char *const strs[4];

    const char* const*       enabledExtensionNames;

    > echo $'#include<stdio.h>\nvoid hello() {puts("hello world!");} int main() { hello();}' | gcc -xc - && ./a.out
    hello world!

    > echo $'#include<stdio.h>\ninline void hello() {puts("hello world!");} int main() { hello();}' | gcc -xc -   && ./a.out
    /usr/bin/ld: /tmp/ccYdbjTB.o: in function `main': 
    :(.text+0xe): undefined reference to `hello'
    collect2: error: ld returned 1 exit status

Any time this comes up I like to point out that the spiral rule is wrong. It is instructive in a way because one learns more about C declaration syntax, but it is even more instructive to recognize why it is wrong.

The spiral rule works only if there is no pointer to pointer or array of array in the type. But take this for example:

        +----------------------------+
        | +-----------------------+  |
        | | +------------------+  |  |
        | | | +-------------+  |  |  |
        | | | | +--------+  |  |  |  |
        | | | | |  +--+  |  |  |  |  |
        | | | | |  ^  |  |  |  |  |  |
    int * * ¦ ¦ ¦ xxx[1][2][3] |  |  |
     ^  | | | | |     |  |  |  |  |  |
     |  | | | | +-----+  |  |  |  |  |
     |  | | | +----------+  |  |  |  |
     |  | | +---------------+  |  |  |
     |  | ---------------------+  |  |
     |  +-------------------------+  |
     +-------------------------------+

The type of xxx is a [1-element] array of [2-element] array of [3-element] array of pointer to pointer to ints. I drew a spiral that passes through each specifier in the correct order.

Notice that to make the spiral correct it has to skip the pointer specifiers in the first three loops. This is marked by ¦. This is not mentioned in the original spiral rules and one could be forgiven to parse the expression as xxx -> [1] -> pointer -> [2] -> etc. following a spiral that doesn't skip the pointers.

The Right-Left Rule is quoted less frequently on HN but it's a correct algorithm for deciphering C types: http://cseweb.ucsd.edu/~ricko/rt_lt.rule.html

The spiral rule can be modified to process all array specifiers before all pointer specifiers, but then you'd have to specify that the order to do so is right and then left. At that point it's just the Right-Left Rule.

I use this rule: Go right when you can, go left when you must.

The real rule turns out to be simple (although non-obvious): "Declaration matches usage."

So, for example, if you want a pointer to a function returning a pointer to an array of 3 integers, you'd want

  (*(*f)())[3 - 1]

to evaluate to an int, so the declaration would be

  int (*(*f)())[3];

Yay, yet another post on HN about mental clutches people use to read C declarations.

It helps a bit browsing through the source code of some of the first C compilers. The Unix Heritage Society[1] hosts source tar balls for very old Unixen, including the first C compilers.

One of the other posts in this thread ("Declaration matches usage.") is pretty close. Basically they originally [ab]used part of the expression parser plus some hacks on top to parse declarations, i.e. something like parsing <type> <expr> ';' and then assigning <type> to the root node and pushing it downwards through the tree to derive the type for the free variables at the leaves.

That's why

  int *a, b;

makes `a` a pointer, but not `b` (and why it's written that way). The int type is assigned to the root node (the `,` operator which has lowest precedence), then pushed to the nodes attached to it. Thus, `b` is derived to be of type `int` as well as ` * a`, which in the next step determines `a` to be of type `pointer-to-int`.

I recall reading a quote from Dennis Ritchie somewhere that the `( * name)` syntax for function pointers was required to "guide the parser" (read: hacks on top), but can't seem to find it right now.

Note that this was all before ANSI times. The current declaration rules have of course been derived and extended from there, but it helps a little understanding some of the oddities.

But even when reading through the C syntax in the first ANSI standard, you might realise that most of the expressiveness in C actually comes from, well it's expression syntax, and you can still shoehorn most of the declaration syntax in there as well, covering probably most of the language syntax using just the expression parser. (Which helps if you are in the 70ies, writing a compiler on a PDP-11 for your little toy OS, unaware that you are building the foundations for lots of things to come after)

[1] https://www.tuhs.org/