Edit: poor grammar
It took another couple of years until I understood what I lacked wasn't time spent reading another section on pointers but additional tooling. Using a debugger and stepping through programs was the next breakthrough.
Looking back today understanding my C (on UNIX) isn't just the language it's a whole ecosystem of tools to measure what is going on and manipulating state so that I can troubleshoot. After gdb came valgrind, strace, lsof, signal handling (kill), process control, gcov, the appropriate type of CFLAGS to use (e.g. the compiler itself) and how to stay sane using Make.
None of them have to do with pointers but they make life a lot easier. To become productive at this takes years but becoming good took me decades. C (imho) isn't just another language but a complete career path with dozens of branches into other areas.
If you stay patient with yourself and treat it as a journey instead of a milestone it can deepen your understanding of systems (nod to eBPF) in situations many others will bail out long before.
Don't give up and then not much will look scary any more.
2) Pointer arithmetic takes into account the size of the type pointed to.
3) The asterisk operator gives you access to the object.
4) The ampersand operator gives you the pointer to the object.
If you understand this, you understand pointers. (The arrow operator is syntactic sugar.)
That is, both a pointer to a single byte and a pointer to a 10GB memory chunk will be of the same size because they just hold a memory location whose value represents where that data starts. Therefore, declaring pointers to a certain type doesn't change their size at all, it just becomes handy when one needs to go back and forth in a memory area in which objects of that type are stored one after another, so that incrementing or decrementing the pointer by a number actually means that number times the size of the objects. Imagine asking for directions to someone and he replies "3rd door" or "3rd building" or "3rd block"; he gave you a pointer that is always the same size, but how much you have to walk will depend on the destination (size).
Once grasped the above, it should become a lot more easy; I had the same problems, then one day had a flash and they became totally clear (and fun).
It may be of help experimenting with a debugger, or simply printf-ing all values a pointer assumes when declared, assigned, incremented/decremented etc. Keep also track of the pointed data values, changing it instead of the pointer, or the other way around, are common mistakes.
An old small command line program like "cdecl" can help a lot to understand complex declarations, and someone has even made an interactive webpage around it (cdecl.org).
example:
cdecl> explain char ((x())[]) () declare x as function returning pointer to array of pointer to function returning char
Do you have any experience in other programming languages? How familiar are you with low-level computer architecture, at the CPU/memory level?
I guess one important part is to realize that in C, variables are basically names for memory locations, that in turn hold values. In other languages variables can be more abstract, and you have no idea how the value(s) are being associated with the variable name.
I started writing an example here, but I ran out of time and it wasn't good enough. :) Sorry.
EDIT: Now I've taken a loo at the relevant pages in the guide itself, and it seemed to explain the concepts very clearly and easily, so ... I'm not sure how to help. :)
A regular variable is a place in RAM that contains a certain value.
A pointer is a variable whose value is the address of another variable.
X = 5
Y = location in memory of X
Now you can use Y to manipulate X
Its long and is filled with other stuff about C programming but it goes in to dept about how to think about pointers. Good Luck!
The quantities added or removed in arithmetic operations are the same as the size of the type that is being pointed to.
Edit: just remembered I wrote a rambling on this in 2014: https://ramblings.implicit.net/c/2014/04/21/pointers-are-not...
https://www.amazon.com/Programming-Language-2nd-Brian-Kernig...
Also, there's nothing magical about pointers - scripting languages use "handles", which is the same thing except they're read-only to the end-user programmer.
The real challenge with C is multi-threaded programming, so don't do that if you don't need it.
It's a great (free as in beer) start.
This is really an amazing feat: books on programming languages age really fast. This one - not so much. And you can really appreciate the careful thought that was put in each sentence. Peerless.
> The real challenge with C is multi-threaded programming, so don't do that if you don't need it.
Well, these days it's harder and harder to avoid it if you want to write efficient apps - we got more cores and the clocks remain more or less the same.
If you know how to walk down a street and stop at the right street number, then you have used pointers. And if you've ever observed that one tall building may "cover" a range of street numbers, such as 200-220, then you should understand how to move from one 4-byte "value" to the next in an array in memory.
Anyway, many more analogies... probably better than this one.
Maybe unions could make using pointers a bit more challenging, but again, tall buildings next to short buildings and so on. We do this kind of pointer calculation in real life.
I think I only understood much of it once I learned Rust, because you realize: Ah, that thing I once did in C is something that maybe ahouldn't be possible at all without extra steps. Even if I were to nwver use Rust again, this definitly helped to understand how to use pointers more safely.
Exposure to an assembler makes pointers easy to understand.
IME languages like Python aren't any easier than C to work with (ignoring UB issues of course), but it's certainly the case that you can probably kinda sorta get your job done with Python even without understanding the first thing of what you're doing, and that's not happening if you write in C.
a = {"one": 1, "two": 2 }
b = a
b["two"] = 99
print(a["two"])
https://www.ralfj.de/blog/2018/07/24/pointers-and-bytes.html
[1] https://www.atlasobscura.com/articles/swazzle-punch-and-judy
C's pointers aren't memory addresses. Ok, they tend to be represented as such at run time, but that's not what the spec actually says the are. And as far as compiler authors are concerned, they can do anything they want as long as it's within spec. Further, the spec even requires some additional behaviors pure memory addresses aren't capable of. See https://www.ralfj.de/blog/2020/12/14/provenance.html for examples of the extra requirements.
Compared to that mess, lambdas are trivial. They're just functions.
I see that as a European, I have virtually no chance to understand pointers using street numbers. :)
(Fortunately I've never had problems either with lambdas or with pointers.)
I've always thought that an introduction to CPUs (can take a simpler one as example) and how they work, how memory is (usually) organised, and to assembly would go a long way in helping understand many programming issues and C.
My experience is that C or programming concepts are often taught in a very abstract/mathematical way, which can be hard to grasp compared to a more practical approach.
If you take a concrete example where memory is effectively an array and indices are addresses (which holds true for most cases and, in any case is a good example) then understanding pointers becomes basically common sense and notations are simply conventions of the language you're using.
https://www.miasap.se/obnc/oberon-report.html
http://people.inf.ethz.ch/wirth/Oberon/PIO.pdfThere's fair amount added to the core since C89, actually... And if you include the library changes, game over! I had no idea how much had been added.
More challenging is to find what's been subtracted.
This no longer defaults to int:
static i;
And gets() is toast.
Anyone know any others?
But yes, the code is also quite different than in K&R which is relatively terse. See for example this comment in K&R about strcpy on print page 105 (page 119 of the PDF)[1], where after showing two versions of strcpy that are pretty readable and easy to follow, the book says:
> In practice, strcpy would not be written as we showed it above. Experienced C programmers would prefer
void strcpy(char *s, char *t)
{
while ((*s++ = *t++) != '\0')
;
}
> the function would likely be written as
void strcpy(char *s, char *t)
{
while (*s++ = *t++)
;
}
I'd have a hard time calling the way they designed _Generic "a nice thing" :-)
Stuff that should be avoided: [...]
Beej's Guide to C: http://beej.us/guide/bgc/output/html/singlepage/bgc.html
Full of mistakes.
[...]
Could someone confirm this? I've seen a lot of threads here on HN praising beej's guides so I am somewhat confused.
[0] http://www.iso-9899.info/wiki/Main_Page
edit: Formatting
And I'm sure it's full of mistakes. It's over 500 pages, most of which has yet to be edited, so if there are fewer than 1000 defects, I'd be shocked.
But I fix them all as I find them, or as they're pointed out. And after an eventual editing pass, things will be better.
And if it's not useful to someone, I take no offense I'd they don't like it. :-)
> When you have a variable in C, the value of that variable is in memory somewhere, at some address. Of course. After all, where else would it be?
It would be in a register. Of course. Or it would be eliminated by a compiler optimization. Of course.
Same error later on:
> When you pass a value to a function,a copy of that value gets made in this magical mystery world known as the stack
No. In most common cases, arguments will not be passed via the stack. This goes on to clarify in a footnote that the implementation might not actually use a stack, and that the stack has something to do with recursion. That part is true, but the values saved on the stack for recursing are not the same as function arguments.
Neither in the Variadic Functions chapter nor anywhere else are the default argument promotions mentioned -- this will bite someone who tries to write a variadic function that gets floats out of the variadic argument list, which you cannot do, since passing a float to a variadic function promotes it to double.
Speaking of floats... This is one of those tutorials that are very confused regarding their target audience. For example, in the "Variables" section it goes out of its way to define: "A “byte” is an 8-bit binary number. Think of it as an integer that can only hold the values from 0 to 255, inclusive." (which isn't the C definition, but this really is nit-picking) but then happily goes on to talk about Booleans and floats without explaining what those are. What reader has a background that would make this useful?
Overall, from the little I've seen, I'd give this an initial rating of "broadly correct but with definite mistakes".
Even if it were fully correct, I dislike the verbose style, and I wouldn't recommend this tutorial. For example, in the Hello World chapter, we have the following "explanation" of the line "#include <stdio.h>":
> Now, what is this#include? GROSS! Well, it tells the C Preprocessor to pull the contents of another fileand insert it into the code rightthere.Wait—what’s a C Preprocessor? Good question. There are two stages (well, technically there are more thantwo, but hey, let’s pretend there are two and have a good laugh) to compilation: the preprocessor and thecompiler. Anything that starts with pound sign, or “octothorpe”, (#) is something the preprocessor operateson before the compiler even gets started. Commonpreprocessor directives, as they’re called, are#includeand#define. More on that later.Before we go on, why would I even begin to bother pointing out that a pound sign is called an octothorpe?The answer is simple: I think the word octothorpe is so excellently funny, I have to gratuitously spread itsname around whenever I get the opportunity. Octothorpe. Octothorpe, octothorpe, octothorpe.Soanyway. After the C preprocessor has finished preprocessing everything, the results are ready for thecompiler to take them and produceassembly code8,machine code9, or whatever it’s about to do. Don’t worryabout the technical details of compilation for now; just know that your source runs through the preprocessor,then the output of that runs through the compiler, then that produces an executable for you to run. Octothorpe.What about the rest of the line? What’s<stdio.h>? That is what is known as aheader file. It’s the dot-hat the end that gives it away. In fact it’s the “Standard I/O” (stdio) header file that you will grow to knowand love. It contains preprocessor directives and function prototypes (more on that later) for common inputand output needs. For our demo program, we’re outputting the string “Hello, World!”, so we in particularneed the function prototype for theprintf()function from this header file. Basically, if we tried to useprintf()without#include <stdio.h>, the compiler would have complained to us about it.How did I know I needed to#include <stdio.h>forprintf()? Answer: it’s in the documentation. Ifyou’re on a Unix system,man printfand it’ll tell you right at the top of the man page what header files are required. Or see the reference section in this book.:-)Holy moly. That was all to cover the first line! But, let’s face it, it has been completely dissected. No mysteryshall remain!
Only one sentence of this is relevant for an introductory Hello World chapter: "Basically, if we tried to use printf() without #include <stdio.h>, the compiler would have complained to us about it." None of the rest is relevant or helpful to a beginner who is just seeing their first ever C program. Also "completely dissected" isn't true either; there is a lot more to be said about headers.
Since you mention relevance for beginners later on in your post I'd argue this isn't relevant either. This concept holds true for simple code that doesn't do advanced stuff like working with hardware. As soon as you do &variable, you get an address and can work with it. If the compiler optimized something away you never use you might as well just pretend it's in memory somewhere for the sake of a mental model that's easy to grasp. Same with passing variables via stack. A simple compiler could do it just like that.
That isn't to say the tutorial is good/not good, but these points in particular seem rather sane to me. Far from "Mastering C Pointers" at least :)
As long as you’re taking, and using, the address of that variable, it’s almost guaranteed to be in memory. Even if it won’t, the compiler guarantees the output of the program will be equivalent to unoptimized code.
> arguments will not be passed via the stack
I’m not sure explaining nuances of various calling conventions, and how they differ across processors and OSes, is useful information in a document about C and targeted towards beginners.
You’re talking about things which are underneath C in the abstraction layer hierarchy. The abstraction has many layers, the lowest one being quantum physics. One has to stop somewhere, and this article decided to stop at C, as opposed to assembly.
Appreciate the feedback. Some good suggestions here that I'll add.
Quite the contrary in my opinion. As a beginner I was very frustrated with most approach that say "Just put that thing that is needed and will be explained latter. And it work good job attaboy!"
And maybe 250 pages latter if the author didn't forgot in the meantime you get a one liner mention that link back to the first introduction of the syntax.
At least this guide don't let the reader in the fog wondering.
Any one remember the heyday of comp.lang.c? I wonder what goes on in there now.
Comp.lang.c was important to me for many years. I've met 5 or so of the regulars at least once. The most famous comp.lang.c regular is probably Tim Hockin of the Kubernetes project.
Reddit has more traffic nowadays.
Also, obsession with ANSI C, analogous to obsession with POSIX shell, is sort of "middlebrow" in the sense that the people who WRITE the spec need to go outside of it to create a new version of it. Good specs are derived from real usage.
[1] C Interfaces and Implementations: Techniques for Creating Reusable Software by David Hanson - HN's tptacek seemed to rave about this book, that's how I heard of it. Wonder what he thinks of it in 2021.
[2] C Programming: A Modern Approach by K. N. King - this one seems to be loved by many. Seems to be more 'beginner-friendly' than the 1st one I guess.
K. N. King "C Programming":
https://accu.org/bookreviews/1999/graham_1260/
Ben Klemens "21st Century C":
https://accu.org/bookreviews/2016/demin_1882/
Robert C. Seacord "Effective C":
Edit: Here's a short rationale for the book by the author.
I'm sort of a C beginner myself. I understand pointers, and I do remember they clicked in my mind suddenly. The moment before, I didn't understand at all. I also love the quirkiness of this guide. Definitely going to give this a read.
This somehow never really clicked (or actually it clicked and declicked somehow)
Putting in the examples for all the calls--I stole that idea from The Turbo C Bible, a book I really loved back in the day... because of the examples.
And C11 only has minimal portable UTF-8 support, but I do talk about it. I think C21 will improve on that a bit.
A note on safety would be well worth it. I'll do that. Good suggestion.
If his guide to C is anywhere near as good it should be an awesome resource.
I liken it to an artisanal craftsman's tool versus a modern multi-tool like a dremel which would be something like python.
Beej's Guide to C Programming - https://news.ycombinator.com/item?id=26100391 - Feb 2021 (1 comment)
Beej's Guide to C Programming (2007) - https://news.ycombinator.com/item?id=15198093 - Sept 2017 (79 comments)
As long as we're talking C programming, I'd single out this large thread with C Standards committee members from last year:
Tell HN: C Experts Panel – Ask us anything about C - https://news.ycombinator.com/item?id=22865357 - April 2020 (962 comments)
These tutorials are the gold standard of tutorials. I wish more content would be as straight to the point and easy to follow.
For anything that one finds as mistakes, the author went out of his way (via references) for the reader to dig further.
> When compiling C,machine codeis generated. This is the 1s and 0s that can be executed directly by the CPU.
No! Tell me about how the code is translated into an ELF executable, linked, has its memory laid out by the OS and then executed.
> I’m seriously oversimplifying how modern memory works, here. But the mental model works, so please forgive me
No! Tell me about how memory works in the C abstract machine which is what you can actually program against and guaranteed by the compiler.
> Nothing of yours gets called before main(). In the case of our example, this works fine since all we want to do is print a line and exit
No! tell that main is special because it's mapped to the _start symbol or at least eventually jumped into by code at that symbol which has an address that's stored by the linker in e_entry.
Like I might be the weird one but this kind of writing (which is common to seemingly all C texts) confuses me more than if it had just been explained.