import this jokes, and I just had to do one for C. And, well, here we are.
First, let’s just see it in action.
1
2
3
4
5
6
7
8
9
10
11
// main.c
#include "this.h"
int main(int argc, char** argv)
{
(void)argc;
(void)argv;
return 0;
}
The first ingredient is our regular C source file. It’s just a main function
that does nothing. The 2nd one, is our secret sauce, we will discuss it later.
And of course, the final ingredient, the C compiler, I’ll use gcc.
So, let’s compile and run it:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
$ gcc -Wall -Wextra -pedantic main.c -o main
$ ./main
The Zen of C, by dweller
Code is better than cliché guidelines.
Working code is better than cute, but broken one.
Simple is better than complex, complex is better than broken.
Simple is not necessarily easy.
Zero cost abstractions is lack of abstractions.
Crash often.
There are usually multiple ways to do it.
Especially if it's multi-platform.
Avoid undefined behavior.
Know your tools, understand your platform.
Code, profile, optimize. In that order.
If the implementation is hard to explain, it may be a bad idea.
Or it may be hard to explain.
Delete more code than you write.
Magic, ain’t it? :) Well, needless to say the magic is in the this.h file. So let’s inspect it.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
// this.h
#ifndef THIS_H
#define THIS_H
#include <stdio.h>
#define main \
__dummy(void) {return 0;} \
int __user_main(int, char**); \
int main(int argc, char** argv) \
{ \
printf("The Zen of C, by dweller\n" \
"\n" \
"Code is better than cliché guidelines.\n" \
"Working code is better than cute, but broken one.\n" \
"Simple is better than complex, complex is better than broken.\n" \
"Simple is not necessarily easy.\n" \
"Zero cost abstractions is lack of abstractions.\n" \
"Crash often.\n" \
"There are usually multiple ways to do it.\n" \
"Especially if it's multi-platform.\n" \
"Avoid undefined behavior.\n" \
"Know your tools, understand your platform.\n" \
"Code, profile, optimize. In that order.\n" \
"If the implementation is hard to explain, it may be a bad idea.\n"\
"Or it may be hard to explain.\n" \
"Delete more code than you write.\n" \
); \
return __user_main(argc, argv); \
} \
int __user_main
#endif // THIS_H
This is the secret sauce. What it does is replaces any symbol main (which is
usually your program entry) with this mess.
First part is __dummy(void) {return 0;}, it simply closes the int that we assume comes before main. After that, it declares a function __user_main
that has the same signature as regular main. Then, we actually declare and
define actual main function, we print our little joke-ish Zen, call
__user_main function with arguments from the shell and return whatever it
returns. And finally, at the end, we simply start the actual definition of
__user_main, as we expect the user’s main implementation after this.
Let’s see the output of C preprocessor, ignoring the stdio.h stuff:
1
$ cpp main.c
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
# 1 "main.c"
# 1 "<built-in>"
# 1 "<command-line>"
# 31 "<command-line>"
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 32 "<command-line>" 2
# 1 "main.c"
# 1 "this.h" 1
// tons of stdio.h stuff...
# 5 "this.h" 2
# 2 "main.c" 2
# 4 "main.c"
int __dummy(void) {return 0;} int __user_main(int, char**); int main(int argc, char** argv) { printf("The Zen of C, by dweller\n" "\n" "Code is better than cliché guidelines.\n" "Working code is better than cute, but broken one.\n" "Simple is better than complex, complex is better than broken.\n" "Simple is not necessarily easy.\n" "Zero cost abstractions is lack of abstractions.\n" "Crash often.\n" "There are usually multiple ways to do it.\n" "Especially if it's multi-platform.\n" "Avoid undefined behavior.\n" "Know your tools, understand your platform.\n" "Code, profile, optimize. In that order.\n" "If the implementation is hard to explain, it may be a bad idea.\n" "Or it may be hard to explain.\n" "Delete more code than you write.\n" ); return __user_main(argc, argv); } int __user_main(int argc, char** argv)
{
(void)argc;
(void)argv;
return 0;
}
If we just massage the code to make it bit more readable, since all of it is on
the same line, plus remove all the cpp stuff. We get:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
// stdio.h stuff...
int __dummy(void) {return 0;}
int __user_main(int, char**);
int main(int argc, char** argv)
{
printf("The Zen of C, by dweller\n"
"\n"
"Code is better than cliché guidelines.\n"
"Working code is better than cute, but broken one.\n"
"Simple is better than complex, complex is better than broken.\n"
"Simple is not necessarily easy.\n"
"Zero cost abstractions is lack of abstractions.\n"
"Crash often.\n"
"There are usually multiple ways to do it.\n"
"Especially if it's multi-platform.\n"
"Avoid undefined behavior.\n"
"Know your tools, understand your platform.\n"
"Code, profile, optimize. In that order.\n"
"If the implementation is hard to explain, it may be a bad idea.\n"
"Or it may be hard to explain.\n"
"Delete more code than you write.\n");
return __user_main(argc, argv);
}
int __user_main(int argc, char** argv)
{
(void)argc;
(void)argv;
return 0;
}
And I think, that’s pretty self-explanatory if you know C. Needless to say, this
has a lot of issues. It works only assuming you include it in the file that
contains main function, and that its signature is int (*)(int, char**),
which is not always true. So this is just a toy to generate a bit of airflow
through some nostrils of a few programmers.
Have a nice one!
]]>Today I want to talk about something that is bugging me lately. As you might’ve guessed from the title, it’s significant whitespace in programming languages.
While I was learning Python, I didn’t give it much of a thought. Now admittedly I do not know Python as much I’d wanted to, but I wrote enough scripts and small tools in it, that I feel comfortable. I haven’t thought of significant whitespace much, because it was new, and it seemed cool. (it makes me format my code (not that it ever was a problem)) But now that I tried Haskell, my opinion changed, and in a bad way.
Okay, so you’re a programmer? You solve problems, you write the solution to it as such that the dumbest thing can understand it - computer. So most of the time programmers drink coffee and stare at the celling are problem solving, and writing the solution down. Therefore, does it seem like a good idea to make a developer think how to write it down, rather than what to write down. In my humble option, you can always refactor the code and/or prettify it later, after the task have been solved.
When I just started to learn Haskell I got a bunch of errors that complained about indentations. That threw me off the track from solving problem on the hand a few times. I wrote possible solution down, tried it, and got errors that are not telling me what is wrong with my solution, but tell me that my code is misaligned. While I try to fix that, I lose my train of thought. (Also what is it about Haskell and tabs? :unset -fwarn-tabs anyone?)
In the end, all I want to say is that in my opinion tools should help us solve the problems, not get in the way. And significant whitespace gets in the way, especially in the beginning.
]]>