Return to IOCCC Year 2025

A “fun challenge” for a winning IOCCC entry is a puzzle or task that an IOCCC judge suggested people consider solving. After you figure out what a given winning entry does, we encourage you to attempt the fun challenge(s).

Some fun challenges ask you to explain something about a winning IOCCC entry. Other fun challenges ask you to produce a variant of the prog.c program that has a different or enhanced behaviour. And still, other types of fun challenges may be posed.

NOTE: Some of these challenges are easier than others.

See the FAQ on “fun challenges” and, to provide a solution, the FAQ on “submitting a solution to a fun challenge”, as well as the FAQ on “opening a pull request”.

This fun challenge is CLOSED.

Modify prog.c so that the code allows for N to be defined for values larger than 11, e.g., that works with -DN=12, and up to some reasonable limit.

GitHub user Master-Hash on 2026 Jun 09 presented this 2025/ayu fun challenge solution.

This fun challenge is still OPEN.

Use the toolchain to compile your own software to run on this VM.

This fun challenge is still OPEN.

Produce a variant of the vmlinux bootimage that contains a C compiler for this VM.

This fun challenge is still OPEN.

Modify prog.c so that the code supports the FORTRAN READ statement.

This fun challenge is still OPEN.

Explain the purpose of the constant 9018655 as used in prog.c.

This fun challenge is still OPEN.

Explain why prog.c prints the number of digits of the constant that it prints.

This fun challenge is still OPEN.

Given the “constant” that is printed, explain the last line of output:

    ./prog | tail -1

This fun challenge is CLOSED.

Modify prog.c so that the code that prints IOCCC 2025 at the very end, in honor of the contest year in which it won, instead of IOCCC 2026. Of course, the digits printed beforehand should remain the same.

Samantha Howard on 2026 Jun 09 presented this 2025/dogon fun challenge 2 solution.

This fun challenge is CLOSED.

Additionally, observe the try.sh script uses the following display the program’s output:

    ./prog | cat

However, the following may, for some environments, print what seems like garbage:

    ./prog

Explain why this command:

    ./prog | cat > foo

may produce, for some environments, different output than the following command:

    ./prog > bar

Ilya Kurdyukov on 2026 Jun 09 presented this 2025/dogon fun challenge 3 solution:

In 2025/dogon/prog.c we find:

    int *e; e=(int*)calloc(-~(e==e)<<-~(!(e>e)<<-~-~-~!(e<e)),-~!(e>e));

The pointer to the integer e is uninitialized in the expressions that form both arguments to the calloc(3) library call.

In some environments, the clang compiler might compile that C code as:

    int *e; e=(int*)calloc(2, 1);

In some environments, the gcc compiler might compile that C code as:

    int *e; e=(int*)calloc(262144, 2);

If you move the declaration of the pointer to the integer int*e; out of main() and into global variable space where it will be initialized to 0, the standard output will be “normal”.

For example, and ignoring the fun layout of 2025/dogon/prog.c:

    --- prog.c      2026-06-09 11:26:01
    +++ prog.fix.c  2026-06-17 00:25:40
    @@ -2,10 +2,11 @@
     #include <stdlib.h>
     #define E printf
     #define F char
    +int*e;


                                                                                                                                         main()
    -           {                                                                                                                    int*e;for(                      e
    +           {                                                                                                                          for(                      e
               =(                                                                                                                   int*)calloc                      (-
              ~(                                                                                                                    e==e)<<-~(!                       (e
              >e                                                                                                                    )<<-   ~-~-                        ~!

When you compile prog.fix.c into prog.fix, the standard output will be “normal”.

This fun challenge is still OPEN.

Modify prog.c so that the code also works with UPPER CASE LETTERS. You would certainly have to embiggen the tube size to better distinguish individual letters and digits. Such code would be a cromulent addition to 2025/endoh1 code.

This fun challenge is CLOSED.

Modify prog.c so that the code prints a line instead of varying brightness of a yellow line, using 256 ANSI Color Codes. Choose a colors/brightness palette to represent the charge intensity.

GitHub user omoikane on 2026 Jun 7 contributed a solution that was added as 2025/endoh2/prog.alt.c.

NOTE: The above mentioned file was added before this page was available. Future solutions to other fun challenges should be presented as external GitHub repos.

See the FAQ on “submitting a solution” for more details.

This fun challenge is CLOSED.

Explain why the git-am patch generator must be used about 25 times (see try.sh for details) to produce a unified diff tool.

Jack Mahoney on 2026 Jul 10 presented this 2025/endoh3 fun challenge solution.

This fun challenge is still OPEN.

Modify prog.c so that the code allows for different map projections. Add -p projection as a command line option to change the default projection. Add this to a debug.c as well for extra points.

NOTE: you will want to provide PPM images for each type you work in. It would be preferable if it was scientific but as the author also provided an equirectangular of Flat Earth for fun, it need not be scientific if you cannot find one or you wish for some fun.

NOTE: the author did NOT use a library so you should make sure to do this as well (in fact trying to use the library would totally break the code and defeat the purpose of some of the obfuscation).

This fun challenge is still OPEN.

Explain why there are four args (in one invocation) but yet the value of argc, g, is only checked once, besides g!= 3 && g < 5 (which should tell you the two forms of invocation).

This fun challenge is still OPEN.

Modify prog.c so that the code renders smaller (or larger) sized arrows, making sure that coordinates at the edge of the map are placed correctly as well as the other coordinates. Add a debug.alt3.c with the same updates.

Hint: To test that the arrows fit on the edge of the map, you should test coordinates such as 0 0, 90 180, -90 0, etc. (I.e., coordinates that cause the arrows to be at the very edge of a map).

This fun challenge is still OPEN.

Modify prog.c the code that solves challenge 2, with a -p projection option.

This fun challenge is CLOSED.

Explain why d has to start at -1 (bonus: experiment with different values and explain what happens and specifically why) and why you can’t change the !=1 in the code:

    if  (d=(c!=e==!d!=d!=d==1&&e!=c)!=1||/* NOW YOU KNOW d IS 1! */fread(c, -*(S[F])-d*3 ,
        b*j,q)^j *j *2)X;

Hint: the above are related to each other.

Antoine Mathys on 2026 Jul 11 presented this 2025/ferguson fun challenge 4 solution.

This fun challenge is still OPEN.

Modify prog.c so that the code is slightly harder to play by allowing the closest invader to be killed. Compensate slightly for that difficulty increase by allowing the shift TAB key to cycle in the opposite direction of the TAB key.

This fun challenge is still OPEN.

Modify prog.c so that the code that has an “Amulet of Yendor”.

In particular, add an “Amulet of Yendor” (similar to the “,” comma character in the rogue 5.4 game) to floor 26. If the player descends below floor 26 without the amulet, place it on that lower floor until the player eventually acquires it. Block the player’s ascent (to a lower floor number) unless they possess the amulet. If the player returns to the top floor 0 with the amulet, display a winning message, and exit.

This fun challenge is still OPEN.

Modify prog.c so that the code displays IOCCC 2025 instead of DOCTOR WHO.

This fun challenge is still OPEN.

Modify prog.c so that the code allows for the use of numbers in the interval [1, 2^31), or even the interval [1, 2^63).

This fun challenge is still OPEN.

Explain how the argument to ./prog determines if input is encoded or decoded.

This fun challenge is still OPEN.

Create a 32K ROM file that tests if 2^p-1, is a Mersenne prime using the Lucas–Lehmer primality test.

This fun challenge is still OPEN.

Create a 32K ROM file that tests if h*2^n-1 is prime, using the Lucas–Lehmer–Riesel primality test. You may find the pages related to the Riesel Test in the A Grand Coding Challenge helpful.

This fun challenge is CLOSED.

Modify prog.c so that the code with a modified p[] array prints the string IOCCC 2025 followed by a newline.

Antoine Mathys on 2026 Jun 09 presented this 2025/ncw2 fun challenge solution.

This fun challenge is still OPEN.

Modify prog.c so that the code draws a Julia set.

This fun challenge is still OPEN.

Explain the purpose of the constant .5, used several times in prog.c. How does changing .5 to a different value affect the generated sound?

This fun challenge is still OPEN.

Write an alternate version of try.sh that detects when the quasi-quine, left to its own iterative devices, starts to repeat.

If you do not attempt to move the paddle, and let the game run on its own, the game should “evolve” to other “modes”, and eventually cycle back to the original style of game play.

This fun challenge is still OPEN.

Implement an additional game mode using only the original game objects (the ball and two paddles).

For example, you could implement a “flappy bird” game using the ball as the bird and the paddles as the pipes.

As an extra challenge, try to keep the original behavior of the program the same, with this new game mode added on top.

This fun challenge is still OPEN.

Create a version of the game that “plays itself”, running through all the gameplay without user input and returning to the exact source code it started with.

This fun challenge is still OPEN.

Modify prog.c so that the code allows for integers, somewhat larger than 9999, to be tested for primality.

This fun challenge is still OPEN.

Modify prog.c so that the code implements the compression algorithm used in the entry as a standalone program outputting a bitstream, and compare its performance with gzip -1.

This fun challenge is still OPEN.

Explain the purpose of the constant 114 in prog.c. Are there any alternative values that could replace 114 without affecting the program’s functionality?