Inconsistencies in C syntax

I will probably update this post later in life, but for now I would like to address this very, very inconsistent syntax in C.

I am talking about the * that we use while dealing with pointers.

Consider this code:

int i, *p;
p = &i;

int q = *p;

This code says:

• “Hey, i is an integer”
• “Hey, p is a pointer variable to i” (i.e p contains the address to i)
• “Assign p to the address of i” (that we get by & operator).
• “Hey, q is another integer which contains the value of whatever p points to” (in our case, it’s i, by * operator).

Here we see two *p’s, with two completely different meaning!

The first *p is used to indicate that p is a pointer variable. The second is used to get the value of whatever p (an address) contains, which is the value of i. In the second case, * is an operator, not an “indicator”.

Fine. Inconsistent, but it makes sense. Right?

Now, consider this:

int i, *p = &i, q = *p;

Can you figure out what this says?

You might have these questions:

• “Shouldn’t it be p = &i instead?” Kinda…
• “Shouldn’t *p = &i give the value of i?” No, it gives the address of i.
• “If q = *p, then isn’t q = &i?” No, q is not declared to be a pointer variable.

Well, you’re right to have these questions. C is a very compact, not-so-verbose language. Often, it’s hard to understand because the meaning is hidden under symbols. And the thing is that in this world of programming, we have too many things to implement, but too few symbols on our keyboard.

To address that “kinda”, which took too many of my braincells, consider:

int i, *p = &i;

Which is a short hand for:

int i, *p;
p = &i;

Both say the same thing. This is what makes things complicated. It should be p = &i, but only if you initialise *p at first.

This is why reading a C codebase is not for GenZ’s. We simply don’t have that much attention span and cognitive endurance to think about nuances. Which is all the more reason we should program in C! And Rust!