Beej’s Guide to C Programming [pdf]
beej.us
beej.us
I'd have a hard time calling the way they designed _Generic "a nice thing" :-)
There'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++)
;
}
while (*s++ = *t++);
All those code samples will crash and burn if s and t point to the wrong locations, t happens to point to a string without a null terminator, or s points to a buffer not big enough to handle the string pointed by t.
This is true for all uses of pointers in C. The only validation you can do is whether a pointer is null. Apart from that you can never know that a pointer points to a non-wrong location. And still experienced C programmers seem to be OK with using pointers.
But even then, most experienced C programmers don't care about using them anyway, that is why Apple, Oracle, Microsoft, ARM, Google, Cambridge university are all leading efforts for hardware memory tagging.
So it won't matter how much they care, as the OS will kill their beloved application when pointers get misused.
A scenario already made reality in platforms like Solaris SPARC.
Are outside the scope of the C language. But if you allow these special APIs, you can use them to implement a safe strcpy. Either way your point from above is still invalid.
Edit:
https://www.stroustrup.com/bs_faq.html#C-is-subset
>Please note that "C" in the paragraphs above refers to Classic C and C89. C++ is not a descendant of C99; C++ and C99 are siblings.
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
But I became disinterested because:
1. Most beginning programmers don't start with C
2. I wouldn't get a chance to go deep and explore the language.
So I shelved it, unfinished.
Flash forward to about a year ago... I had flash of inspiration: change the audience to intermediate programmers.
Now I could skim the general conceptual stuff and get into more details.
One thing, though. C actually added a lot of stuff in the intervening years. I didn't realize the magnitude of the project.
Oh well! Too late to turn back now!
Except literally every indian engineer. They teach C to mechanical and chemical engineers for some reason. (It's not an elective)
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 :)
Agreed. At the time that variables are introduced, it should just say "a variable is a name for a location where a value is stored". I didn't mean to suggest that the tutorial should go into needless detail at that point. Just that the needless detail that it currently goes into is wrong.
> Same with passing variables via stack.
Again, my problem is just with the needless detail. When you pass a value it is copied (that is the relevant part) somewhere where the callee can find it (that somewhere is the irrelevant part).
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.
As soon as you mention the stack, you've gone beyond C and started talking about something that is not C.
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.
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.
- typedef struct { ... } foo
- foo *foo_create()
- void foo_destroy(foo *)
- a bunch of functions that take foo* as their first arg
which is kind of the same as a class and only more error-prone.
I say this as someone who actually _likes_ C, but the manual memory management model is very often unnecessary, confusing, repetitive. There was an idea some time ago of a language extension that would extend the concept of automatic storage duration to allow an explicit destructor to be called when the variable goes out of scope, like <close> variables in some languages. I genuinely think things like that would make the language a bit more ergonomic without fundamentally changing its nature.
foo f;
foo_init(&f);
foo_destroy(&f);
...
foo *g = malloc(sizeof(foo));
foo_init(g);
foo_destroy(g);
free(g);I would write the allocation as
foo * const g = malloc(sizeof *g);
In the case you show, foo would have to be a struct that doesn't contain pointers to additional allocated memory, but its a entirely valid use case and pattern.
Calling malloc and free, has a cost associated with it, that the stack doesn't. But stack can in some cases, like with recursion be scary to use, because you dont know where it ends. If malloc returns NULL you know you have found the end and can do something reasonable.
Thanks for you insight!
In GPU programming, there are actual different memory sub-systems, with different sizes and different performance implications, so it’s critical that the caller is able to do the allocation & deallocation any way they want. This is why most well designed GPU APIs rarely allocate GPU memory inside the API, but instead are designed to work with caller-provided pointers to buffers.
There is a much more advanced design and implementation at “A defer mechanism for C” (December 2020): https://gustedt.wordpress.com/2020/12/14/a-defer-mechanism-f...
For my own purposes, I think I can live without handling stack unwinding so I continue working on my pre-processor.
Since the pre-processor is not yet finished, there I use a vector¹ of {.pointer, .destructor} where I put objects after initialization, with one macro at the end of each managed scope that calls the destructors for that scope in reverse order, then another macro meant for the function exit points that calls all the destructors in that vector. This has been built many times before by other people of course, it’s just an exercise to see which difficulties arise.
¹ Vector, growable array: I did my own trivial type-generic growable array, with the classic {.capacity, .len, .items}, but again there are many previous implementations. The two I’ve found more interesting are:
- “C Template Library (CTL)”: https://github.com/glouw/ctl
- “Klib: a Generic Library in C”: https://github.com/attractivechaos/klib/
#define P
#define T int
#include <vec.h>
#define T vec_int
#include <deq.h>
https://github.com/tezc/sc/tree/master/array
It is just an array of your type, e.g int *numbers, so you have type info in debugger as well.
What do you mean by broken alignment?
The alignment is broken because nothing in the C standard guarantees that the elems member of sc_array will be aligned correctly for any possible element type.
I also spotted another problem, in sc_array_init the code `void *p = a` is also not guaranteed to work. In an example snippet such as `int iv; sc_array_create(iv, 0);` expands to `sc_array_init(&iv, sizeof iv, 0)` so the type of the expression `&iv` is `int *` which is then being converted to `void *` in the function which is actually not allowed by the standard. This is also the reason why if you were writing a wrapper around realloc which exited if the allocation failed you would still have to pass in the current pointer with void * and return the new pointer with void *. This could be applied here actually as an easy fix but it indicates even further to me that the author of the library is taking a very leisurely approach to writing conforming C. This pattern also appears in the other two functions though and I'm not sure if in those cases it's something which can be easily fixed.
IIRC clang implements it as well, but I wasn’t able to find a reference to it in their docs.
struct X { int a; }
struct Y { *X; int b; int c;}
void add(Y* self, int number) {
self->a += number;
}
Y y;
y.a = 10; // composition
y.add(1) // y.a = 11 now
The other extension i would add is some sort of interface or protocol.
As soon as you can do something like "y.add(1)", having a generic contract to refer to things without having to know its concrete type is some of the good things from the OOP world.
With this you would also be able to call some cleanup code and even a initializer.
This is still C and its still much simpler than C++, and yet almost as powerful.
C should propose these kind of things even if it was not that conservative and it would retain a lot of coders that migrate instead giving C barely evolved from its 70's roots.
Unless you decide you use libgc, presumably?
a = {"one": 1, "two": 2 }
b = a
b["two"] = 99
print(a["two"])
I know it's probably baseless, but I can't shake the feeling that people who learn modern languages before learning C are just making their own lives harder.
[0] https://www.instructables.com/CARDIAC-CARDboard-Illustrative...
Here is a great “rant” at it in case of Java:
def foo(mylist=[]): mylist.append("a") return mylist
mylist is only initialized once, so the function will actually return one more "a" with each function execution
def foo(x, cache={}):
if x in cache:
return cache[x]
val = cache[x] = x*x+1
return val
# hash
my %a = ( 'one' => 1, 'two' => 2 );
my %b = %a;
$b{ 'two' } = 99;
# prints 2
print $a{ 'two' }, "\n";
# reference to hash
my $a = { 'one' => 1, 'two' => 2 };
my $b = $a;
$b->{ 'two' } = 99;
# prints 99
print $a->{ 'two' }, "\n";Most dynamic languages expose the data as references. In fact, the one thing that trips up JavaScript developers (especially in React) is that they do not understand how references work. I see senior and lead developers inadvertently doing mutation all the time. Or getting incredibly paranoid that two identical strings, for example, do not equal each other in the strictest sense in JS. They also throw in memoization everywhere due to their fundamental lack of understanding.
You can always tell the developers that do not have C/C++/Pascal experience.
[1] https://en.wikipedia.org/wiki/Sigil_(computer_programming)
Same goes for arrays, `int *x[30]` just says that `*x[30]` is an `int` (well, technically it's out of bounds by 1), thereby we're declaring an array of 30 int-pointers.
Of course, that hasn't been entirely true since function declaration changed with ANSI C in the late 80s or so.
When using that variable with the allowed operators, the resultant type of the expression is determined by the declaration:
pa; // int *[10]
pa[x]; // int *
*pa[x]; // intAnd unary operators on an identifier are a different thing, though I similarly don’t think adding one at the left, another at the right is a good thing. But I have trouble with the declaration site as well.
It’s getting out of reach of my knowledge, but I believe C’s grammar being hacky is in part due to that as well.
I didn’t find exactly what I was looking for but here is some more on it: https://pdos.csail.mit.edu/archive/l/c/roskind.html
int * a, b;
Then typedef comes along and ruins everything:
typedef int * pint;
pint c, d; int a, *b, (*c)(int);https://www.ralfj.de/blog/2018/07/24/pointers-and-bytes.html
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.
Thank you for your reply...
The "very abstract" way C is taught actually prevents people from making such assumptions by not priming them to make them. The fact that people get complacent and start to lean on their understanding of (what they think are) real machines to write C is the result of the bugs I mentioned in the previous response.
https://www.miasap.se/obnc/oberon-report.html
http://people.inf.ethz.ch/wirth/Oberon/PIO.pdf[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.
Any one remember the heyday of comp.lang.c? I wonder what goes on in there now.
Reddit has more traffic nowadays.
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.
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.
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.
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)
For anything that one finds as mistakes, the author went out of his way (via references) for the reader to dig further.
Edit: poor grammar
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. :)
Essentially, they don't/can't know anything about anything, at the most fundamental levels of their construction, and have to be hand-held every tiny step of the way.
A computer is essentially a highly complex arrangement of on/off switches - there's little else fundamentally in there doing anything at all other than something causing the first switch to cycle between on and off states and cascade to all the rest (this isn't entirely accurate but it's close enough to make te point).
This gives rise to situations where in order to create greater levels of complexity, lots of unintuitive, and seemingly even pointless things need to be done. For example: assigning letterbox addresses to every discrete portion of memory. Then things like "I want to read the values from this part of memory up to this part" require laboriously adding 1 to a value (a pointer) that tracks which address the computer is currently "thinking" about. It's so stupid it needs to remember where it is all the time like this, or it can't do anything.
Because C is very close to this mundane and laborious fundamental architecture, it (usefully in that case) deals with concepts like "pointers".
In languages at just a bit higher level, the language internals deal with pointers so that we as programmers don't have to.
http://pythontutor.com/c.html#mode=edit
If you click down to the bottom and choose from the examples "Pointer Levels" you'll get a good idea of the tools powers.
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.
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.
There was some article a few years ago that said the apps they looked at didn't actually run faster after making some routines parallel, so it depends, and you will definitely have more debugging to do.
It's a great (free as in beer) start.
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...
Subtracting two pointers yields ptrdiff_t which is not a pointer type in itself.
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
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.
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!
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
[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.
> 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.
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.
If his guide to C is anywhere near as good it should be an awesome resource.
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.
I liken it to an artisanal craftsman's tool versus a modern multi-tool like a dremel which would be something like python.