I checked the section "Interlude: Arrays" because the relationship between pointers and arrays in C is a major sticking point.<p>It claims that, given a declaration<p><pre><code> int array[] = { 45, 67, 89 };
</code></pre>
the expressions "array", "&array", and "&array[0]" are all equivalent. They are not. "&array" and "&array[0]" both refer to the same memory location, but they're of different types.<p>In the next section:<p>"By the way, though sizeof(void) is illegal, void pointers are incremented or decremented by 1 byte."<p>Arithmetic on void pointers is a gcc-specific extension (also supported by some other compilers). It's a constraint violation in standard C.<p>I don't think this is the "best" article on pointers in C.<p>I usually recommend section 6 of the comp.lang.c FAQ, <a href="http://www.c-faq.com/" rel="nofollow">http://www.c-faq.com/</a>
I don’t have my copy at hand, but <i>Expert C Programming: Deep C Secrets</i> has the best coverage of pointers and arrays I’ve seen.<p>In particular, it supplies a useful algorithm for decoding all pointer declarations such as functions that return function pointers.<p><a href="https://www.goodreads.com/book/show/198207" rel="nofollow">https://www.goodreads.com/book/show/198207</a>
Ah, boxes again.<p>For me, all confusion about C's pointer-happiness cleared up when I finally realized that C (and Asm, I guess) works with heap memory as a big blob of bytes, and it's programmer's job to keep the blob's contents from getting messed up―with some thinly-veiled help from the language and the compiler. Everything else, including variables, is just syntactic sugar when it points to the heap.<p>(With the clarification that afaik variables are different when they're on the stack or registers, becoming first-class 'indivisible' entities).
The title claims everything, but certainly it doesn't cover everything. It mentions const but doesn't mention volatile. It also doesn't mention restrict which is more confusing than const/volatile. It didn't mention the strict aliasing rule. It actually didn't even mention NULL.
No C pedantry thread would be complete without a link to one of the finest resources on the subject: <a href="https://blog.regehr.org/" rel="nofollow">https://blog.regehr.org/</a>
I've always been partial to Dennis Kubes' five minute guide:<p><a href="https://news.ycombinator.com/item?id=4389691" rel="nofollow">https://news.ycombinator.com/item?id=4389691</a>
I always wonder what makes pointers so difficult for some. So far I have always been able to explain it to people by drawing a linear memory space and then showing how different types are allocated. It seems to me that pointers are one the easier concepts in programming.
When graphical gimmics steal the show: <a href="https://boredzo.org/pointers/boxes.png" rel="nofollow">https://boredzo.org/pointers/boxes.png</a> visualizes both pointers and their target (an integer) as 3d boxes. So the sizeof(int) is the edge length of this target?<p>Normally we see such guiding images with 2d boxes. There's nothing wrong with 3d because clearly, integers are also not 2d (they are not even 1d). However, don't associate the size of theses boxes with the memory size of an element. This overstresses the analogy and suggests the whole thing is a vector space, but it isn't.
This is why people think programming is difficult. That same article could have been written in a significantly less convoluted way, and had a much broader reach, particularly for people who aren't already at least moderately familiar with C.
I joked the other day to a co-worker, currently working full time in Python, that you get used to the list comprehension and other nice things of Python so much, that you'll never be able to go back to gnarlier languages like Java/C. It's just too nice. You can get python to run really fast nowadays and if you can't, you still got nim.