A practical hacker’s guide to the C programming language.
In memory of Dennis Ritchie,
one of the greatest hackers this world has known.
This book assumes basic programming knowledge. We’re not going to spend a lot of time and space on explaining basic features, except where they behave differently in important ways compared to other mainstream languages. Instead we’re going to focus on practical techniques for making the most out of the power and flexibility C offers.
You could say that there are two kinds of programmers, with very different motivations; academics and hackers. I’ve always identified as a hacker. I like solving tricky problems, and I prefer using powerful tools that don’t get in my way. To me; software is all about practical application, about making a change in the real world.
I’ve been writing code for fun on a mostly daily basis since I got a Commodore 64 for Christmas in 1985, professionally in different roles/companies since 1998.
I started out with Basic on the Commodore 64, went on to learn Assembler on an Amiga 500, Pascal on PC; C++, Modula-3, Prolog, Ruby, Python, Perl, JavaScript, Common Lisp, Forth, Haskell, SmallTalk, Go, Swift.
For a long time, I didn’t care much about C at all, it felt very primitive compared to other languages. But gradually over time, I learned that the worst enemy in software is complexity, and started taking C more seriously.
Since then I’ve written a ton of C; and along the way I’ve picked up many interesting, lesser known techniques that helped me make the most out of the language and appreciate it for its strengths.
If you would like to see this project succeed, all contributions are welcome.
I’ve decided to release the project using an open license to benefit as many as possible, because I believe knowledge should be shared freely. But I also believe in compensati
10 Comments
kelsey978126
For those also wondering like myself, this refers to hacker in the whiny "security hacking is only called cracking Reeeee" manner, so this is just aimed at programmers and not security professionals.
akdev1l
> Microsoft has unfortunately chosen to neglect C for a long time, its compilers dragging far behind the rest of the pack.
Is this still true? MSVC is pretty good at compiling C++ nowadays
lou1306
> Using a stricter language helps with reducing some classes of bugs, at the cost of reduced flexibility in expressing a solution and increased effort creating the software.
First of all, those languages do not "help" "reducing" some classes of bugs. They often entirely remove them.
Then, even assuming that any safe language with unsafe regions (Rust, C#, etc) would not give you comparable flexibility at a fraction of the risk… if your flexible, effortless solution contains entire classes of bugs, then there is no point in comparing "effort". You should at least take into account the effort in providing a software with a high confidence that those bugs are not there.
throwaway7894
That's just diabolical. I would not have thought to write "case __LINE__". In the case of a macro, using __LINE__ twice expands to the same value where the macro is used, even if the macro has newlines. It makes sense, but TIL.
pjmlp
> The reason I believe C is and always will be important is that it stands in a class of its own as a mostly portable assembler language, offering similar levels of freedom.
When your computer is a PDP-11, otherwise it is a high level systems language like any other.
9d
> C doesn't try to save you from making mistakes. It has very few opinions about your code and happily assumes that you know exactly what you're doing. Freedom with responsibility.
I love C because it doesn't make my life very inconvenient to protect me from stubbing my toe in it. I hate C when I stub my toe in it.
throwaway7894
As someone who has a file with similar hacks, I will say this: I am not a C++ fan, but if you find yourself writing C code where you simulate methods via structs with function pointers often, just use C++ as a basic "C with classes" at that point. You want methods anyway, you have to go through a pointer dereference to call the function, it's just not worth the code weirdness. If you have the grit to use structs with function pointers everywhere, you have the grit to stick to the simpler subset of C++.
steinuil
Some points about the introduction, but otherwise this seems like an interesting collection of (slightly deranged?) patterns in C.
> The truth is that any reasonably complicated software system created by humans will have bugs, regardless of what technology was used to create it.
"Drivers wearing seatbelts still die in car accidents and in some cases seatbelts prevent drivers from getting out of the wreckage so we're better off without them." This is cope.
> Using a stricter language helps with reducing some classes of bugs, at the cost of reduced flexibility in expressing a solution and increased effort creating the software.
…and a much smaller effort debugging the software. A logic error is much easier to reason about than memory corruption or race condition on shared memory. The time you spend designing your system and handling the errors upfront pays dividends later when you get the inevitable errors.
I'm not saying that all software should be rewritten in memory-safe languages, but I'd rather those who choose to use the only language where this kind of errors regularly happens be honest about it.
_false
Honest q: after skimming through the book it's unclear how it's targeted towards hackers (c.f. academics)?
talles
Any quick way to make a PDF out of this?