In a chapter about deconstructing someone else's book, your own book also does dangerous things according to yourself:
> The problem is, as with every book with code ever in the universe, beginners will copy that code out and use it somewhere else and then the function is wrong.
Yet, if a beginner copied some of the code in this chapter they'd have the exact bug you are talking about here (using the NULL pointer returned from malloc()).
I think you should probably expand that into the safer checks (don't forget to free(line) if longest is NULL too!).
Are we looking at the same code? I use an assert to quickly check for NULL, and this is a simple example of how to work with the function. Other parts of the book use more extensive error checking and I use my debug.h macros quite a lot, but if you find bugs feel free to email me them. I'd really appreciate it.
I'm referring to this code on the originally linked page [1] (you'll have to scroll back a bit because your header blocks the content).
In the context of this thread, brghts states that this is dangerous because if you compile with -DNDEBUG the assert is optimized away.
So if I copy that code with the assert statement, it will be optimized away and your code no longer performs the NULL check. This is bad.
As you mention, beginners tend to copy code off the Internet and cause bugs. If you recognize this and claim to be teaching people you should not use bad practices in your example code. Period.
If you don't want to muddy the waters with your custom debug macros, then you should still play it safe when checking return values the a beginner may simply copy and think is correct.
I seem to get a 500 error page whenever I search for something along the lines of "NOT label:css". I was hoping to be able to find issues that are not labeled as something.
Other than that this seems like a great improvement!
You should be creating a dict vs. a namedtuple instance once, then accessing it many, many times. What you're doing is creating a lot of dict vs. namedtuple instances, then accessing each one only once. That's mostly testing the instance creation time, not the field access time.
Ah, ok, I see, for some reason my browser wasn't showing the namedtuple code snippet right. Now I need to go look at the namedtuple code to see why accessing the fields by name is slower than accessing them by index.
Yep. Because the dictionary literal gets created via opcodes in the interpreter loop whereas the named tuple pays the price of calling a function and setting up an interpreter frame.
My reading of the docs[1] has always led me to believe that it doesn't. For example, "It is possible to provide a setup statement that is executed only once at the beginning"
To answer your question directly, no I don't think so (perhaps some updated theories, but nothing concrete).
But the article does cover more than just the incident, I found the whole thing fairly interesting.
Beyond the passing knowledge I have from growing up in Chicago-land around the time and the Wikipedia article on the subject, I thought it contextualized the FCC policies around the time of the incident and how the hack worked (from a high level). It also pointed out other signal intrusions from the same period and the FCC/FBI's methods to track down the perpetrators.
