K&R is easily one of the best CS/programming books. Short, concise and to the point.

Another way to learn pointers is via assembly. Either learn assembly or just look at the disassembled code. Look under the hood and it'll become clearer.

Of course the best way is to write your own C compiler... but that may be overkill for most.

> Rather more surprising, at first sight, is the fact that a reference to a[i] can also be written as * (a+i)

I did not find that all that surprising, but the first time I saw that a[i] can also be written as i[a], I was very irritated.

I don't know. I read the pointers chapter at least 3 times, and I still get confused when I see pointer stuff in real code. The other day, I read the famous regex post by Russ Cox[1], and it took me a couple of hours to understand the pointer parts of the code even though the algorithm behind it was relatively simple. I guess pointers are just one of those things that for some people make a lot of sense, whereas others struggle with.

[1] https://swtch.com/~rsc/regexp/regexp1.html

>> A pointer is a variable that contains the address of a variable.

Well, it is a little bit incomplete I think. A pointer contains both the address of a variable and a type. That is why pointer arithmetic works. Without type of pointer, p++ is not calculatable.

The pointer variable does not contain the type - it only stores the address. Sizeof will return whatever the machine address width is.

The type is implicitly stored as the pointers type. Casting a pointer can change a piece of memory to be interpreted as any type you want. Although the cast might not make logical sense or may even caused undefined behavior in C.

Pointer arithmetic works off of whatever the current type is, as the compiler needs to know how to the memory offsets.

I actually meant that pointer type is also important to understand the concept. I may not have stated it well. Yes, it does not store the type of the variable it points to but type of the pointer matters and it is significant because many operations depends on it.

C beginner here. I think you stated it well : "and a type" The post you responded to on the contrary misses your point that in memory a pointer is a variable that stores both an address and type information to what it points to.

No, it does not. The compiler knows the pointer type so that it can generate correct assembly, but the pointer type is not something stored in memory past the compilation phase.

> A pointer is a variable that contains the address of a variable.

Given the way the C-standard is relatively carefully written, that explanation is a useful lie, but not necessarily true in every implementation of C.

Sure. When you study physics you first learn Newtonian gravitation; and later, once you really master it, you learn that it is actually false and proceed to learn general relativity. In a similar way, it is very useful for people who learn C to start with the idea that "a pointer is an int". Then, they can discover that pointers are not really ints, but not before they have mastered working with pointers as if they were ints.

Could you explain (or link to a good resource about) what pointers really are? I'm surprised that they aren't just ints that point to the address of a variable.

In all modern implementations that I know of, pointers are effectively ints. But the formal definition of the C language takes great care in not saying that, allowing for implementation to chose how to implement pointers. In some older systems, for example in 16-bit MS-DOS with "high memory", pointers were not really ints, but pairs of ints (called the segment and the offset, if I recall correctly) whose mapping to memory positions was overlapping, i.e., non unique, you could have very different representations for the same memory position. I guess the gcc port to MSDOS by DJ Delorie had to deal with these issues somehow.

But it is possible to imagine completely exotic CPU architectures, where there is a separate type of register that can only be used for pointers and it is impossible to convert to int; you could still write C compilers for that architecture and be 100% conforming to the standard.

If I remember 16 bit C compilers let you choose a couple of different memory models. I remember 3, data and code fits in 16bits. data is 16 bits and code is segment and offset. And both pointers are segment and offset. I think there were more, especially for systems with 'high memory'

Most processors a pointer just gets stuffed into a register and then that's used by a assembly instruction to read/write a memory location. But it's certainly possible to have systems where it's not so simple.

They are variables that store an address. Usually they are of integer-ish thing internally, but this is in no way required, just like C has no need to run on a machine with linear memory. You could have a variable to memory hash table backing all your objects, for example, with a pointer that is a bucket or something.

This is the kind of thing that you need a significant other to straighten out.

"Hey!"

(smacks on head)

"It's an int that points to a variable."

"Now get off the computer and take out the trash without talking about garbage collection!"

"but it could be an int32_t and sometimes..."

(smack)

This is what you want to read: https://blog.regehr.org/archives/1621

No, it’s correct. The statement makes no claims about how the pointer is stored, but semantically it is a variable with the information in it to locate another variable.

This is true, as long as your definition of "another variable" stretches far enough to include memory regions allocated by malloc. And (leaving the C standard), also things allocated through other means, like memory-mapped files, and things like like memory-mapped peripherals.

In other words, the statement is incorrect.

I was specifically responding to the comment above, which had clearly conflated the standard not specifying the representation of a pointer with “anything anyone says about pointers isn’t actually correct”. Keeping the standard in mind the definition of “variable” generally extends to “any typed memory regardless of whether it has a name or not”, and the pointers K&R are talking about are fairly clear to mean this in the sense of the pointer being dereferenceable to a specific type. That being said, you are correct that there are other pointers not mentioned in that statement that are an entirely separate class from normal data pointers: untyped buffers, usually specified by void * but (for legacy reasons) often char * as well. And of course, there’s also function pointers that you dereference only to call them.

Um, why wouldn't it be correct to call any/all of thoes examples a variable?

They’re not variables until they’ve been specified a type, which is at the point you first assign to the memory in a typed fashion I believe. It’s significantly more pedantic than the first line in an introductory text will go into, though ;)

Nah, that's wrong. A variable doesn't need a type. Case in point; void.

All variables have types in C. You can't declare a "void" variable. You can declare a void function. Try assigning it to a variable. You can't. void pointers (void*) are a different story.

So just the opposite of what the comment you replied to suggested:

'void' is a type, but in C values of the type void are not first class. Ie a function can return a value of type void, but you can't assign it to a variable.

I'm not sure what you mean, could you explain a bit more?

Are you saying void is not a type?

It is a good book. But to be fair, not many modern languages are as simple (low number of concepts) as C.

> A pointer is a variable that contains the address of a variable.

Doesn't it technically also contain its own address? So it contains the address of another variable and the address of itself. Pointers are hard...

A variable "contains" only its (current) value. That's the only use of "contains" that makes sense to me.

You can "get" the address of a variable (or more generally, of any l-value) with the & operator. That operator is nothing else but an "escape" character that says "Dear C, I don't want you to load the current value of that variable. Give me just the address where it lives so I can load it later".

(Same applies to storing instead of loading)

> Doesn't it technically also contain its own address

Huh? Then you probably don't understand the meaning of "contains" here. Or what variables are in general. Variables are hard...

Well, the way I see it is this: you, as a person, contain your thoughts and possessions and so on - call it your value. But you also exist in space and time, you have a defined location. You don't carry it in your pocket, it's something you implicitly contain.

Nope. And they're not really. Imagine a simple computer with, say, 32 bytes of ram.

All our bytes of ram are numbered. We read a value from byte number 8 and that value is 17.

"Byte number 8" is a pain to remember or calculate so we give it a label and let the computer keep track. That's a "variable".

What does that 17 mean though? Is it a value we want to use later on? It might be. Or it could be referring to Byte 17 in our ram. Byte 17 happens to have the value 42 so if we use Byte 8 as a pointer that's the value we end up with.

But it's entirely our choice. It's just a number and we can treat it as a value or a pointer to another memory address as we like.

No, that would be a pointer to a pointer.