Stories
Slash Boxes
Comments

SoylentNews is people

posted by martyb on Monday May 07 2018, @01:44PM   Printer-friendly
from the do-you-see-what-I-did-there? dept.

The International Obfuscated C Code Contest (IOCCC) has now posted the winning entries from its 25th event. The summary of winning entries does NOT contain brief explanations of each winning entry, so you can try to spot the tricks yourself. If you don't mind seeing a brief summary of each entry, there is an alternate page with spoilers linked to from the main page.

The goals of the IOCCC are to write the most Obscure/Obfuscated C program within the contest's rules, while showing the importance of programming style, in an ironic way. It stresses the C compilers with unusual code and illustrates some of the subtleties of the C language. Lastly it provides a safe forum for poor C code.


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 4, Funny) by The Mighty Buzzard on Monday May 07 2018, @04:23PM (8 children)

    Most all of my C is naturally obfuscated. Sometimes I'm so good at it that even I can't read it the very next day.

    --
    My rights don't end where your fear begins.
    Starting Score:    1  point
    Moderation   +2  
       Insightful=1, Funny=1, Total=2
    Extra 'Funny' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   4  
  • (Score: 2) by bob_super on Monday May 07 2018, @05:30PM (6 children)

    by bob_super (1357) on Monday May 07 2018, @05:30PM (#676696)

    I've actually had to threaten to fire a guy who used acronyms for all his variables, and never wrote a line of comment. His stuff was working, but was unmaintainable, maybe not even by him.
    He was nice enough to find somewhere else to be.

    • (Score: 0) by Anonymous Coward on Monday May 07 2018, @06:15PM (1 child)

      by Anonymous Coward on Monday May 07 2018, @06:15PM (#676719)

      Gotta save those bytes man!

      I have never found typing speed to be the bottle neck, so I try and keep my variables reasonably descriptive.

      • (Score: 1) by redneckmother on Monday May 07 2018, @06:36PM

        by redneckmother (3597) on Monday May 07 2018, @06:36PM (#676729)

        (See a porting project description below)

        I'm not much of a typist (school of seek and ye shall find), so I employ "search and replace" to improve function / procedure / variable / parameter names... I usually start out with some funky short string as a name, then s/r to a descriptive one. Sheesh, modern editors - who'd a thunk it?

        After much wailing and gnashing of teeth, I converted a coworker to using the same technique - he had been partial to using variable / parameter names like "j1", "j2", etc. for both locals and globals. He also gained appreciation for documentation in comments. Oftentimes, comments explaining intent are helpful for identifying logic and coding errors.

        --
        Mas cerveza por favor.
    • (Score: 4, Interesting) by redneckmother on Monday May 07 2018, @06:21PM (3 children)

      by redneckmother (3597) on Monday May 07 2018, @06:21PM (#676721)

      Used to develop in assembly language - had a hard time deciphering some x86 source for a port to another device. The x86 author was steadfastly opposed to using comments, and was fond of saying, "Well, it's obvious what this routine does." Hell, even the name of the routine didn't come close to hinting the intent. The original source was heavily hand- optimized for both size and instruction cycle counts, sometimes using obscure register "side effects". Don't miss trying follow that dick's crap.

      The target device was proprietary, and the ported application was tested nightly (in Japan) during the project. The testers were VERY thorough, albeit not fluent in English ("Step 1: Press space key 512 time" ... "Step 49: Press Enter" ... "Error is occurred"). They uncovered some GLARING logic errors that existed in the x86 code, which I had faithfully ported. The lesson I learned is that, no matter how good the pay, a functional port from well documented code is a MUCH preferred task. And yes, I commented the crap out of my port.

      --
      Mas cerveza por favor.
      • (Score: 0, Disagree) by Anonymous Coward on Monday May 07 2018, @06:53PM (1 child)

        by Anonymous Coward on Monday May 07 2018, @06:53PM (#676738)

        optimized for both size and instruction cycle counts,

        Not possible.

        • (Score: 0) by Anonymous Coward on Monday May 07 2018, @07:14PM

          by Anonymous Coward on Monday May 07 2018, @07:14PM (#676756)

          Yes, it is. Less opcodes means (usually) less clock cycles.

      • (Score: 2) by jb on Tuesday May 08 2018, @07:26AM

        by jb (338) on Tuesday May 08 2018, @07:26AM (#676936)

        The x86 author was steadfastly opposed to using comments

        I've never understood that attitude.

        Surely assembly language (for any given target architecture) has got to be the language that encourages comments more than any other. After all, isn't that why the instructions are all so short -- so there's room left over for a comment on every line?

        The same held true even back when 40-column displays were a thing -- with 80+ cols to play with, there's really no excuse...

        On the other hand, I feel your pain with deciphering x86 code. That's one instruction set that seems to have been designed to discourage readability (which only makes good comments even more important...).

  • (Score: 2) by RS3 on Tuesday May 08 2018, @01:02AM

    by RS3 (6367) on Tuesday May 08 2018, @01:02AM (#676852)

    Most all of my C is naturally obfuscated.

    There's too much artificially obfuscated C. It's heartwarming that you're greening up the code and getting back to nature.