4 ms·

The source itself: http://ioccc.org/2013/cable3/cable3.c http://ioccc.org/2013/cable3/cable3.c Or after running through preprocessing (not a huge help I found,

The source itself: http://ioccc.org/2013/cable3/cable3.c http://ioccc.org/2013/cable3/cable3.c Or after running through preprocessing (not a huge help I found, sadly): https://gist.github.com/peterc/8259713 https://gist.github.com/peterc/8259713

mschuster91 13y ago
Did you do this by hand? Line 38 looks weird: main(BX,nE)charnE; {
- sdevlin 13y ago
  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.
  - mschuster91 13y ago
    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...
    - someaccount 13y ago
      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.
    - petercooper 13y ago
      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 :)
      - bunderbunder 13y ago
        Sounds about right. The author mentions using K&R style function declarations as a way of shaving bytes in his writeup, too.
      - mschuster91 13y ago
        Ah, thanks for the explanation. Looks like the author did a deep, deep dive in the C language specs!
        hafflelog 13y ago
        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.
- petercooper 13y ago
  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.
  - midas007 13y ago
    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.
    - faragon 13y ago
      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.
nitrogen 13y ago
Strangely, visiting that Gist, GitHub asks me to log in. When I visit in a private browsing window, the Gist is displayed. Wasn't Google doing something like this, preventing registered users with an old cookie from seeing public content without signing in?

mschuster91 13y ago

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

sdevlin 13y ago
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.
- mschuster91 13y ago
  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...
  - someaccount 13y ago
    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.
  - petercooper 13y ago
    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 :)
    - bunderbunder 13y ago
      Sounds about right. The author mentions using K&R style function declarations as a way of shaving bytes in his writeup, too.
    - mschuster91 13y ago
      Ah, thanks for the explanation. Looks like the author did a deep, deep dive in the C language specs!
      - hafflelog 13y ago
        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.
petercooper 13y ago
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.
- midas007 13y ago
  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.
  - faragon 13y ago
    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.

nitrogen 13y ago

Strangely, visiting that Gist, GitHub asks me to log in. When I visit in a private browsing window, the Gist is displayed. Wasn't Google doing something like this, preventing registered users with an old cookie from seeing public content without signing in?