Hacker News Reader

Comment by mschuster91 | Hacker News Reader

Did you do this by hand? Line 38 looks weird: main(BX,nE)charnE; {

That's an old-school C function declaration. Note that the function return type are parameter types are implicitly int. nE is then explicitly declared to be a char pointer pointer.

But the char is outside of the declaration and before the opening brace - is this legal? And especially, why isn't it written like main(BX,charnE)? Doesn't save any bytes,it rather adds one semicolon...

Because it's not entirely about size, it's an obfuscation contest. Anything strange or unusual, especially something most people haven't seen used, will help obfuscate the code.

Yes, it's very old fashioned (K&R era).

I think the reason for doing it this way rather than putting the type declaration alongside the parameter is then it would also demand also adding an int declaration for the BX parameter which would then cause the code to be longer. That is to say with:

    main(BX,char**nE){

.. it would throw an expected identifier error on the char. So you'd be putting the original:

    main(BX,nE)n**nE;{

Against this error-free alternative:

    main(int BX,n**nE){

.. but that's one byte longer.

If I got any of this wrong, I hope someone will correct me though :)

Sounds about right. The author mentions using K&R style function declarations as a way of shaving bytes in his writeup, too.

Ah, thanks for the explanation. Looks like the author did a deep, deep dive in the C language specs!

K&R predates the specs, actually. C89 codified the current C parameter convention. Compilers typically continue to support K&R style for very old C code and because it doesn't break modern C support.

No, just passed through gcc -E which essentially preprocesses the file only (in this case in order to unpack all the defines) without fully compiling.

For those that don't know C, basically preprocessing (cpp, gcc -E, clang -E) is one of the first steps to occurs before the C compiler is invoked. It's easiest to think of the preprocessor as a templating language that can be used (or abused) to DRY up code and make it easier to maintain and customize. So the only thing that ever really gets compiled is the amalgamated processed .c files altered and configured by .h files and preprocessor options.

In this case, even with the preprocessor and using "indent", the code is non-understandable. It requires a huge effort of deobfuscation (operator precedence mess, re-"macrofy" the code -as after expansion is very redundant, etc.). From the 4KB it goes to 30KB. After re-"macrofying" the code it drops to 15KB of somehow understandable code. It is a beautiful piece of code, no doubt.

Reply on news.ycombinator.com