Why was the C syntax for arrays, pointers, and functions designed this way?

Question

After having seen (and asked!) so many questions similar to

What does int (*f)(int (*a)[5]) mean in C?

and even seeing that they'd made a program to help people understand the C syntax, I can't help but wonder:

Why was the syntax of C designed this way?

For example, if I were designing pointers, I would translate "a pointer to a 10-element array of pointers" into

int*[10]* p;

and not

int* (*p)[10];

which I feel most people would agree is much less straightforward.

So I'm wondering, why the, uh, unintuitive syntax? Was there a specific problem the syntax solves (perhaps an ambiguity?) that I'm unaware of?

Answer 1

My understanding of the history of it is that it's based on two main points...

Firstly, the language authors preferred to make the syntax variable-centric rather than type-centric. That is, they wanted a programmer to look at the declaration and think "if I write the expression *func(arg), that'll result in an int; if I write *arg[N] I'll have a float" rather than "func must be a pointer to a function taking this and returning that".

The C entry on Wikipedia claims that:

Ritchie's idea was to declare identifiers in contexts resembling their use: "declaration reflects use".

...citing p122 of K&R2 which, alas, I don't have to hand to find the extended quote for you.

Secondly it is actually really, really difficult to come up with a syntax for declaration that is consistent when you're dealing with arbitrary levels of indirection. Your example might work well for expressing the type you thought up off-the-bat there, but does it scale to a function taking a pointer to an array of those types, and returning some other hideous mess? (Maybe it does, but did you check? Can you prove it?).

Remember, part of C's success is due to the fact that compilers were written for many different platforms, and so it might have been better to ignore some degree of readability for the sake of making compilers easier to write.

Having said that, I'm not an expert in language grammar or compiler writing. But I know enough to know there's a lot to know ;)

Answer 2

A lot of the oddities of the C language can be explained by the way computers worked when it was designed. There were very limited amounts of storage memory, so it was very important to minimize the size of the source code files themselves. The programming practice back in the 70s and 80s was to make sure the source code contained as few characters as possible, and preferably no excessive source code comments.

This is of course ridiculous today, with pretty much unlimited storage space on hard drives. But it is part of the reason why C has such weird syntax in general.

---

Regarding array pointers specifically, your second example should be int (*p)[10]; (yeah the syntax is very confusing). I would perhaps read that as "int pointer to array of ten"... which makes sense somewhat. If not for the parenthesis, the compiler would interpret it as an array of ten pointers instead, which would give the declaration an entirely different meaning.

Since array pointers and function pointers both have quite obscure syntax in C, the sensible thing to do is to typedef away the weirdness. Perhaps like this:

Obscure example:

int func (int (*arr_ptr)[10])
{
  return 0;
}

int main()
{
  int array[10];
  int (*arr_ptr)[10]  = &array;
  int (*func_ptr)(int(*)[10]) = &func;

  func_ptr(arr_ptr);
}

Non-obscure, equivalent example:

typedef int array_t[10];
typedef int (*funcptr_t)(array_t*);


int func (array_t* arr_ptr)
{
  return 0;
}

int main()
{
  int        array[10];
  array_t*   arr_ptr  = &array; /* non-obscure array pointer */
  funcptr_t  func_ptr = &func;  /* non-obscure function pointer */
  
  func_ptr(arr_ptr);
}

Things can get even more obscure if you are dealing with arrays of function pointers. Or the most obscure of them all: functions returning function pointers (mildly useful). If you don't use typedefs for such things, you'll quickly go insane.

Answer 3

It's pretty simple: int *p means that *p is an int; int a[5] means that a[i] is an int.

int (*f)(int (*a)[5])

Means that *f is a function, *a is an array of five integers, so f is a function taking a pointer to an array of five integers, and returning int. However, in C it isn't useful to pass a pointer to an array.

C declarations very rarely get this complicated.

Also, you can clarify using typedefs:

typedef int vec5[5];
int (*f)(vec5 *a);

Answer 4

I think you have to consider * [] as operators that are attached to a variable. * is written before a variable, [] after.

Let's read the type expression

int* (*p)[10];

The innermost element is p, a variable, therefore

p

means: p is a variable.

Before the variable there is a *, the * operator is always put before the expression it refers to, therefore,

(*p)

means: variable p is a pointer. Without the () the [] operator to the right would have higher precedence, i.e.

**p[]

would be parsed as

*(*(p[]))

Next step is []: since there is no further (), [] has higher precedence than the outer *, therefore

(*p)[]

means: (variable p is a pointer) to an array. Then we have the second *:

* (*p)[]

means: ((variable p is a pointer) to an array) of pointers

Finally you have the int operator (a type name), which has the lowest precedence:

int* (*p)[]

means: (((variable p is a pointer) to an array) of pointers) to integer.

So the whole system is based on type expressions with operators, and each operator has its own precedence rules. This allows to define very complex types.

Answer 5

It's not so hard when you start thinking and C never was very easy language. And int*[10]* p really isn't easier than int* (*p)[10] And what type of k would be in int*[10]* p, k;