The 5-minute Guide to C Pointers

- "The cast isn’t explicitly needed in C but it does make things more readable" - I think many people would disagree with this, including me. Casting is ugly, error prone, and conceals errors. Don't do it, there is no need. If you think it is helping you because you can see what type things are then your functions are too large and incoherent, fix that problem instead.

- "Here we print out the values of our uninitialized and NULL pointers. Notice that our uninitialized pointer has a memory location" - This behaviour is completely undefined and it is doing injustice to those who would benefit from this blog post. All code people run on an example site should be well-defined. "Worst case the program crashes badly" - No, worst case is you have no idea what could happen! Old versions of gcc ran nethack when it detected undefined behaviour at compile time. In practice, crashing is actually the best case since you can see the error. In worst case it silently corrupts data in your program and you can't find it until it's so far from the error site that it's near impossible to track down.

- "using the NULL keyword" - NULL is not a keyword, it's a macro defined in stddef.h (maybe stdlib.h? I forget).

- "doing so will cause a segmentation fault" - No, it's undefined behaviour. On DOS systems the memory addresses 0 was valid and writable.

- "That being said an array variable does point to the memory address of the first element of the array." - No, it IS the first element. It decays to a pointer to its first element under various operations, though.

- "char * fullname = "full name";" - const char * . Modifying string literals is undefined and the fact that the compiler does not require fullname to be a const char * is merely a historic oversight.

I understand the desire to learn-by-writing, but I don't feel this tutorial offers much to the discussion and confuses some of the same things the many other pointer tutorials confuse. I don't think someone new to pointers will actually come out with a superior understanding of pointers after reading this. Much of the content is not technically wrong the wording and method of introduction isn't any less confusing.

Again, maybe it just shows my age, as I started coding with BASIC and Z80 assembly.

C was made so that it could be simply compiled to assembly. Also important, it had high portability "in mind". The mix of these two design goals is that compilers could exist for many platforms. And not just that, it's a language that was made also so that a large part of the UNIX operating system could be re-written in.

As some additional, although you can interpret C, that's not how it's usually used. In teaching/learning, people use optimizing (professional) compilers such as GCC. Which leads to a much non-interactive environment.

Put these 2 design goals together and you're bound to realize a language which is not beginner friendly because lots of things are there, or not, for reasons (a) to help the compiler writers; (b) due to portability on some machine of the 70's or 80's; and (c) of being a language for OS development. Add this with the fact that the tools around the language are not so interactice, you get something really beginner unfriendly.

C is not simple to learn, to use or to get good at. Compilers take advantage of what was put in the standard in very bizarre ways. Which means that if your code is wrong, even a little bit, it's likely that you get bugs, terrible ones. The optimizing compilers (good for professional use; bad for leaning) are usually the ones which will lead to the strangests bugs. Again, not beginner friendly.

It's often that people think they're good at C, and that they write portable C code: they usually are not and don't. C is very good at deceiving people.

Unfortunately, C is not a language that you can just pick and start solving your problem right away. Many more ordinary statements can fail for non-obvious reasons, which is not so common in other languages.

I am not implying that you don't know all this. I am though, implying that you should take this into consideration when you talk about learning C, and beginner programmers approaching C, and even beginners in C from other languages.

There are good books which are not difficult, and do not let go of preciseness, like K&R2.