Geoff Wozniak

There's also this infamous textbook: https://wozniak.ca/blog/2018/06/25/1/index.html >Why is this important? As I read the book (and if you read my notes, you know where this is going) I started to notice something in the wording and tone. The further I progressed the more I became convinced of it, and I think it explains how he managed to mangle the explanation of C pointers so badly. >I don’t think he understands the call stack. [...] >Suppose you’re used to writing BASIC for small memory electronic devices and you learn about C. You read about pointers and realize something: it’s possible to write a subroutine that can change variables without knowing their names. It’s manna from heaven! You don’t have to devote global variables to being the “parameters” of your subroutines anymore. Life is great. >This is the mindset I think Traister had and never got past.

It's not Steve Wozniak. They just happen to share the same last name. From https://wozniak.ca: > I’m Geoff Wozniak, just one of those persons on the Internet. My blog is hosted here, but not much else at the moment.

> Sometimes they did not work despite being to all appearances character for character the same as the book, and I was often left with no idea why. The book may have been wrong - between 2000 and 2005 there were a ton of programming books that were flat out wrong. Many of these were C books. Just one example: the examples from https://wozniak.ca/blog/2018/06/25/1/index.html are full of UB and are almost guaranteed to crash.

Noticed that https://wozniak.ca/blog/2024/01/02/1/index.html (on the HN hompeage as I write this) was serving a 451 response, which I’ve never seen before.

Reminds me a bit of the "Mastering C Pointers" book that was popular in the early 90s and contained a multitude of outright errors. https://wozniak.ca/blog/2018/06/25/1/index.html

Those can be even worse, because the publishing company is also not an expert and just wants to get a book out the door. e.g.: https://wozniak.ca/blog/2018/06/25/1/index.html In this it is a writer who is arguably knowledgeable in one programming language (BASIC) writing a book about another (C) and getting fundamental things wrong. Being a domain expert in one even relatively close area doesn't mean it automatically applies in another.

What ORMs have taught me: Just Learn SQL https://wozniak.ca/blog/2014/08/03/1/index.html

Is it equivalent? Because that seems to be the only difference between the two editions for the newprint function, and the author says one of them happens to compile. https://wozniak.ca/blog/2018/06/25/1/code.html

> Expressions “return a value.” Yes, "returning" is problematic, because that has a very specific meaning in the context of a function call. But even if we forgive the author the inaccurate terminology, it is also an incorrect statement. You can evaluate an expression. But in C in particular, an expression does not necessarily evaluate to a value. A somewhat better statement might be: "Expressions can be evaluated. Some expressions produce a result value." This statement can probably further improved upon; it definitely still does not capture everything that expressions are in C: such as being able to cause side-effects! That might not be evident, but can certainly be important. But then again, I am not writing a book about C. > “A pointer is a special variable that returns the address of a memory location.” Indeed "returning" is problematic here. A pointer does not return anything, it points to something. > Somehow I feel this was written with an air of superiority, the author doesn't expand on anything. I get that feeling a lot with articles about c If you're going to write a book about C in order to teach programmers how to work with pointers, better explain things with the correct terminology. If this were a journal, then of course you can forgive the inaccuracies. But it's a published book that supposedly teaches certain concepts to readers. The author of the blog post says as much in their notes: "This provides some insight into the mind of the author: he's…