Hacker News Reader

Comment by zrail | Hacker News Reader

The author addresses this in footnote #2. They're simplifying the C code to get to the point of the article faster.

I don't really buy that this is a simplification. This code isn't even guaranteed to work on correct input.

A really simple fix would be just to use a character array.

Hmm, that footnote was very hard to notice, so I was quick to point out these errors to the person who maintains the blog, only to get blocked by her on twitter. Not sure why go that far.

Because, if you're going to criticize the article, maybe go read everything there is to read? Because every one of your points was addressed somewhere in the article.

The footnote was very difficult to spot.

Furthermore, I am not sure why not write out the complete code, even if the author knew the code was not correct, even when pointed out, it would have been very trivial to initialize the variable.

Because the author made a stylistic choice to publish slightly incomplete code to get to the point faster (and pointed that out in a footnote, which was just as easy to spot as the "bug"). The point of the essay is not a perfectly executed C program, it's to demonstrate code disassembly and reverse engineering. More attention on perfect C code means less attention (reader attention and author attention alike) on the essential facts the author is trying to communicate.

In addition, I'm not an expert at this stuff, but it seems like initializing that variable would make the disassembly more complex and thus obfuscate the point just that much further.

Regarding your last sentence. Reverse Engineering is a complex task, and obfuscation is but one of the many challenges a reverse engineer faces, granted malloc/free or stack variable and the example binary not being one of them.

The title of the essay starts with "A Gentle Primer". Think less "this is a complex and deep thing that is hard to understand" and more "check out this neat thing you can do with computers! computers are awesome!"

The gist accompanying the article of the full source code contains the same bug. I'm not convinced it was a stylistic choice in the blog for a clearer explanation.

I would expect the full code to be correct/complete. This type of bug goes well beyond "I also make some assumptions in string handling that are considered gravely unsafe to use in a modern program, so please do not use this code in the real world." IMO.

The C code is literally the least interesting part of this essay. This bug, such as it is, does not matter. It is entirely and completely beside the point.

Simplifying does not mean incorrect. Initializing the variable would not add appreciable complexity to the code. It's a snippet and should be fixed lest it make the author appear incompetent.

I'm not 100% confident, but I'm pretty sure the author does not care if you think they're incompetent. The author's skill and apparent interest is in explaining an inherently difficult concept (reverse engineering a complied executable) in a way that won't cause their audience (not you) to tune out and/or go running for the hills.

Could they adjust the snippet? Sure. Will it add anything to the essay to do so? Nope.

Eh... I'm not really buying it. I think it was an honest mistake. C'mon; this makes that snippet harder to read?

    char input[SIZE];

I really don't think so. I'm all for simplifying example code to get the core concept across, but I wouldn't go as far as to invoke undefined behavior. I also don't understand the use of scanf. At all. A seasoned, competent C user would never consider using scanf.

Anyway, I didn't mean to derail things too much here. It's really a nitpick and has little to do with the article itself.

Forget the author appearing competent, this is a primer. Primers should have code you can copy and paste and be correct every time. Most beginner following along running into a weird issue with the program they're using to reverse engineer before even getting to the fun part are just going to give up.

I would expect an article on reverse engineering to have correct C code.

If you think that having undefined behavior in your code is fine as long as it works for you, do not be surprised that one moment a vile dragon appears and starts spewing fire.

The author was wrong, and then corrected their post. Why get indignant on their behalf?

The wrongness, such as it was, is completely beside the point. The author's audience is a group of people where this has a high probability of this being their first exposure to any C at all. That `malloc` is one more thing for them to get tripped up and distracted by.

I'm indignant because this happens on almost every marginally interesting article that makes the front page and I'm sick of it. I get that the code was wrong and a bug and C must be correct at all times or the world will literally light on fire. It's just exhausting reading comment after comment about the tiniest little nit in an otherwise perfectly wonderful essay.

C must be correct at all times or the world will literally light on fire.

Yes, this is frustrating. It's why we try not to write anything in C anymore.

Reply on news.ycombinator.com