Let's look at the source of stdbool.h:

    #define true 1
    #define false 0

http://clang.llvm.org/doxygen/stdbool_8h_source.html

That simply explains the truth behind the words. Re-type-ing basic types into other names gives us the ability to share intent without commentary. A function returning 'bool' is intended to be treated as having two valid return values. A function returning int might be intended to return any of the large rage of values that int can support.

You're missing

   #define bool _Bool

Since bool wasn't reserved prior to C99, they use the _Bool keyword (which was reserved). [http://stackoverflow.com/questions/8724349/difference-betwee...]

I know that sdtbool actually contains macros for defining true and false, but _Bool is a new type in C99 ... But it is in the standard, implemented by all major compilers, so it should be used for the sake of clarity.

IMHO this:

    bool is_valid(char* password);

is more clear than this:

    int is_valid(char* password);

But here's the thing: in the assembly (the very essence of the essay), booleans are still represented as integers. Using a standard macro would obfuscate the path to getting to the payoff of being able to switch a single byte from 0 to 1 and crack the program, because the author would then have to explain macros and delve into a bunch of ancillary stuff.

Starting to work with Reverse Engineering assumes prior knowledge of programming and/or some basic information about assembly for the specific platform.

Furthermore as the examples are given in C, it is implied that the reader needs to be familiar with the language, and as a consequence, knowing about macros, should be if not a given, then at least required.

The original audience of this content (i.e. not HN) is a broad interest group so you can't really assume that kind of knowledge. Again, think "hey this is neat!" vs "this is absolutely technically correct in all ways."

Of course it should be bool.

I'm glad that the OP at least made it a const char *password though, since that's also a must-have. Always const input pointers. And local temporaries. And everything else that you can const, except scalar arguments pretty much.

Given that more than half of that file is a copyright comment, and the other half basically has to follow a standard exactly, it almost makes me wonder if it meets the minimum threshold of creativity to be copyrightable.