There is a rule called the"Clockwise/Spiral Rule" to help find the meaning of a complex declaration.

Fromc-faq:

There are three simple steps to follow:

1. Starting with the unknown element, move in a spiral/clockwise direction; when ecountering the following elements replace them with the corresponding english statements:

   [X] or[]
   => Array X size of... or Array undefined size of...

   (type1, type2)
   => function passing type1 and type2 returning...

   *
   => pointer(s) to...

2. Keep doing this in a spiral/clockwise direction until all tokens have been covered.

3. Always resolve anything in parenthesis first!

You can check the link above for examples.

Also note that to help you there is also a website called:

http://www.cdecl.org

You can enter a C declaration and it will give its english meaning. For

void (*(*f[])())()

it outputs:

declare f as array of pointer to function returning pointer to function returning void

EDIT:

As pointed out in the comments byRandom832, the spiral rule does not address array of arrays and will lead to a wrong result in (most of) those declarations. For example forint **x[1][2]; the spiral rule ignores the fact that[] has higher precedence over*.

When in front of array of arrays, one can first add explicit parentheses before applying the spiral rule. For example:int **x[1][2]; is the same asint **(x[1][2]); (also valid C) due to precedence and the spiral rule then correctly reads it as "x is an array 1 of array 2 of pointer to pointer to int" which is the correct english declaration.

Note that this issue has also been covered in thisanswer byJames Kanze (pointed out byhaccks in the comments).

The "spiral" rule kind of falls out of the following precedence rules:

T *a[]    -- a is an array of pointer to TT (*a)[]  -- a is a pointer to an array of TT *f()    -- f is a function returning a pointer to TT (*f)()  -- f is a pointer to a function returning T

The subscript[] and function call() operators have higher precedence than unary*, so*f() is parsed as*(f()) and*a[] is parsed as*(a[]).

So if you want a pointer to an array or a pointer to a function, then you need to explicitly group the* with the identifier, as in(*a)[] or(*f)().

Then you realize thata andf can be more complicated expressions than just identifiers; inT (*a)[N],a could be a simple identifier, or it could be a function call like(*f())[N] (a ->f()), or it could be an array like(*p[M])[N], (a ->p[M]), or it could be an array of pointers to functions like(*(*p[M])())[N] (a ->(*p[M])()), etc.

It would be nice if the indirection operator* was postfix instead of unary, which would make declarations somewhat easier to read from left to right (void f[]*()*(); definitely flows better thanvoid (*(*f[])())()), but it's not.

When you come across a hairy declaration like that, start by finding theleftmost identifier and apply the precedence rules above, recursively applying them to any function parameters:

         f              -- f         f[]            -- is an array        *f[]            -- of pointers  ([] has higher precedence than *)       (*f[])()         -- to functions      *(*f[])()         -- returning pointers     (*(*f[])())()      -- to functionsvoid (*(*f[])())();     -- returning void

Thesignal function in the standard library is probably the type specimen for this kind of insanity:

       signal                                       -- signal       signal(                          )           -- is a function with parameters       signal(    sig,                  )           --    sig       signal(int sig,                  )           --    which is an int and       signal(int sig,        func      )           --    func       signal(int sig,       *func      )           --    which is a pointer       signal(int sig,      (*func)(int))           --    to a function taking an int                                                  signal(int sig, void (*func)(int))           --    returning void      *signal(int sig, void (*func)(int))           -- returning a pointer     (*signal(int sig, void (*func)(int)))(int)     -- to a function taking an intvoid (*signal(int sig, void (*func)(int)))(int);    -- and returning void

At this point most people say "use typedefs", which is certainly an option:

typedef void outerfunc(void);typedef outerfunc *innerfunc(void);innerfunc *f[N];

But...

How would youusef in an expression? You know it's an array of pointers, but how do you use it to execute the correct function? You have to go over the typedefs and puzzle out the correct syntax. By contrast, the "naked" version is pretty eyestabby, but it tells you exactly how tousef in an expression (namely,(*(*f[i])())();, assuming neither function takes arguments).

In C, declaration mirrors usage—that’s how it’s defined in the standard. The declaration:

void (*(*f[])())()

Is an assertion that the expression(*(*f[i])())() produces a result of typevoid. Which means:

• f must be an array, since you can index it:

  f[i]

• The elements off must be pointers, since you can dereference them:

  *f[i]

• Those pointers must be pointers to functions taking no arguments, since you can call them:

  (*f[i])()

• The results of those functions must also be pointers, since you can dereference them:

  *(*f[i])()

• Those pointers mustalso be pointers to functions taking no arguments, since you can call them:

  (*(*f[i])())()

• Those function pointers must returnvoid

The “spiral rule” is just a mnemonic that provides a different way of understanding the same thing.

So this "reading spirally" is something valid?

Applying spiral rule or usingcdecl are not valid always. Both fails in some cases. Spiral rule works for many cases, butit is not universal.

To decipher complex declarations remember these two simple rules:

• Always read declarations from inside out: Start from innermost, if any, parenthesis. Locate the identifier that's being declared, and start deciphering the declaration from there.

• When there is a choice, always favour[] and() over*: If* precedes the identifier and[] follows it, the identifier represents an array, not a pointer. Likewise, if* precedes the identifier and() follows it, the identifier represents a function, not a pointer. (Parentheses can always be used to override the normal priority of[] and() over*.)

This rule actually involveszigzagging from one side of the identifier to the other.

Now deciphering a simple declaration

int *a[10];

Applying rule:

int *a[10];      "a is"       ^  int *a[10];      "a is an array"        ^^^^ int *a[10];      "a is an array of pointers"    ^int *a[10];      "a is an array of pointers to `int`".  ^^^

Let's decipher the complex declaration like

void ( *(*f[]) () ) ();

by applying the above rules:

void ( *(*f[]) () ) ();        "f is"            ^  void ( *(*f[]) () ) ();        "f is an array"             ^^ void ( *(*f[]) () ) ();        "f is an array of pointers"          ^    void ( *(*f[]) () ) ();        "f is an array of pointers to function"                  ^^     void ( *(*f[]) () ) ();        "f is an array of pointers to function returning pointer"       ^   void ( *(*f[]) () ) ();        "f is an array of pointers to function returning pointer to function"                     ^^    void ( *(*f[]) () ) ();        "f is an array of pointers to function returning pointer to function returning `void`"  ^^^^

Here is a GIF demonstrating how you go (click on image for larger view):

_{The rules mentioned here is taken from the bookC Programming A Modern Approach by K.N KING.}

It's only a "spiral" because there happens to be, in this declaration, only one operator on each side within each level of parentheses. Claiming that you proceed "in a spiral" generally would suggest you alternate between arrays and pointers in the declarationint ***foo[][][] when in reality all of the array levels come before any of the pointer levels.

As a random trivia factoid, you might find it amusing to know that there's an actual word in English to describe how C declarations are read:Boustrophedonically, that is, alternating right-to-left with left-to-right.

Reference:Van der Linden, 1994 -Page 76

I doubt constructions like this can have any use in real life. I even detest them as interview questions for the regular developers (likely OK for compiler writers). typedefs should be used instead.

Regarding the usefulness of this, when working with shellcode you see this construct a lot:

int (*ret)() = (int(*)())code;ret();

While not quite as syntactically complicated, this particular pattern comes up a lot.

More complete example inthis SO question.

So while the usefulness to the extent in the original picture is questionable (I would suggest that any production code should be drastically simplified), there are some syntactical constructs that do come up quite a bit.

The declaration

void (*(*f[])())()

is just an obscure way of saying

Function f[]

with

typedef void (*ResultFunction)();typedef ResultFunction (*Function)();

In practice, more descriptive names will be needed instead ofResultFunction andFunction. If possible I would also specify the parameter lists asvoid.

I happen to be the original author of the spiral rule that I wrote oh so many years ago (when I had a lot of hair :) and was honored when it was added to the cfaq.

I wrote the spiral rule as a way to make it easier for my students and colleagues to read the C declarations "in their head"; i.e., without having to use software tools like cdecl.org, etc. It was never my intent to declare that the spiral rule be the canonical way to parse C expressions. I am though, delighted to see that the rule has helped literally thousands of C programming students and practitioners over the years!

For the record,

It has been "correctly" identified numerous times on many sites, including by Linus Torvalds (someone whom I respect immensely), that there are situations where my spiral rule "breaks down". The most common being:

char *ar[10][10];

As pointed out by others in this thread, the rule could be updated to say that when you encounter arrays, simply consume all the indexesas if written like:

char *(ar[10][10]);

Now, following the spiral rule, I would get:

"ar is a 10x10 two-dimensional array of pointers to char"

I hope the spiral rule carries on its usefulness in learning C!

P.S.:

I love the "C isn't hard" image :)

I found method described by Bruce Eckel to be helpful and easy to follow:

Defining a function pointer

To define a pointer to a function that has no arguments and no return value, you say:

void (*funcPtr)();

When you are looking at a complex definition like this, the best way to attack it is to start in the middle and work your way out. “Starting in the middle” means starting at the variable name, which is funcPtr. “Working your way out” means looking to the right for the nearest item (nothing in this case; the right parenthesis stops you short), then looking to the left (a pointer denoted by the asterisk), then looking to the right (an empty argument list indicating a function that takes no arguments), then looking to the left (void, which indicates the function has no return value). This right-left-right motion works with most declarations.

To review, “start in the middle” (“funcPtr is a ...”), go to the right (nothing there – you're stopped by the right parenthesis), go to the left and find the ‘*’ (“... pointer to a ...”), go to the right and find the empty argument list (“... function that takes no arguments ... ”), go to the left and find the void (“funcPtr is a pointer to a function that takes no arguments and returns void”).

You may wonder why *funcPtr requires parentheses. If you didn't use them, the compiler would see:

void *funcPtr();

You would be declaring a function (that returns a void*) rather than defining a variable. You can think of the compiler as going through the same process you do when it figures out what a declaration or definition is supposed to be. It needs those parentheses to “bump up against” so it goes back to the left and finds the ‘*’, instead of continuing to the right and finding the empty argument list.

Complicated declarations & definitions

As an aside, once you figure out how the C and C++ declaration syntax works you can create much more complicated items. For instance:

//: C03:ComplicatedDefinitions.cpp/* 1. */     void * (*(*fp1)(int))[10];/* 2. */     float (*(*fp2)(int,int,float))(int);/* 3. */     typedef double (*(*(*fp3)())[10])();             fp3 a;/* 4. */     int (*(*f4())[10])();int main() {} ///:~

Walk through each one and use the right-left guideline to figure it out.Number 1 says “fp1 is a pointer to a function that takes an integer argument and returns a pointer to an array of 10 void pointers.”

Number 2 says “fp2 is a pointer to a function that takes three arguments (int, int, and float) and returns a pointer to a function that takes an integer argument and returns a float.”

If you are creating a lot of complicated definitions, you might want to use a typedef.Number 3 shows how a typedef saves typing the complicated description every time. It says “An fp3 is a pointer to a function that takes no arguments and returns a pointer to an array of 10 pointers to functions that take no arguments and return doubles.” Then it says “a is one of these fp3 types.” typedef is generally useful for building complicated descriptions from simple ones.

Number 4 is a function declaration instead of a variable definition. It says “f4 is a function that returns a pointer to an array of 10 pointers to functions that return integers.”

You will rarely if ever need such complicated declarations and definitions as these. However, if you go through the exercise of figuring them out you will not even be mildly disturbed with the slightly complicated ones you may encounter in real life.

Taken from: Thinking in C++ Volume 1, second edition, chapter 3, section "Function Addresses" by Bruce Eckel.

Remember these rules for C declares
And precedence never will be in doubt:
Start with the suffix, proceed with the prefix,
And read both sets from the inside, out.
-- me, mid-1980's

Except as modified by parentheses, of course. And note that the syntax for declaring these exactly mirrors the syntax for using that variable to get an instance of the base class.

Seriously, this isn't hard to learn to do at a glance; you just have to be willing to spend some time practising the skill. If you're going to maintain or adapt C code written by other people, it'sdefinitely worth investing that time. It's also a fun party trick for freaking out other programmers who haven't learned it.

For your own code: as always, the fact that somethingcan be written as a one-liner does't mean it should be, unless it is an extremely common pattern that has become a standard idiom (such as the string-copy loop). You, and those who follow you, will bemuch happier if you build complex types out of layered typedefs and step-by-step dereferences rather than relying on your ability to generate and parse these "at one swell foop." Performance will be just as good, and code readability and maintainability will be tremendously better.

It could be worse, you know. There was a legal PL/I statement that started with something like:

if if if = then then then = else else else = if then ...

• void(*(*f[]) ()) ()

Resolvingvoid >>

• (*(*f[]) ()) () = void

Resoiving() >>

• (*(*f[]) ()) = function returning (void)

Resolving* >>

• (*f[]) () = pointer to (function returning (void) )

Resolving() >>

• (*f[]) = function returning (pointer to (function returning (void) ))

Resolving* >>

• f[] = pointer to (function returning (pointer to (function returning(void) )))

Resolving[ ] >>

• f = array of (pointer to (function returning (pointer to (functionreturning (void) ))))

• c
• parsing
• pointers
• function-pointers
• void-pointers