From 951a42b8ffb47651f04648b54f7fba4086033702 Mon Sep 17 00:00:00 2001 From: Cody Boone Ferguson <53008573+xexyl@users.noreply.github.com> Date: Tue, 5 Aug 2025 09:22:40 -0700 Subject: [PATCH 1/6] Fix html links in 2024/ Due to a manifest mix-up (which had some html files marked as markdown and as display_via_github as true) the respective entries' index.html linked to html files on GitHub which do not render right (and is the wrong place in any case). This means that the index.html files and the .entry.json files were updated. This in particular goes for: 2024/burton 2024/ferguson1 2024/howe Thanks to @SirWumpus for reporting this! --- 2024/burton/.entry.json | 6 +++--- 2024/burton/index.html | 2 +- 2024/ferguson1/.entry.json | 8 ++++---- 2024/ferguson1/index.html | 4 ++-- 2024/howe/.entry.json | 4 ++-- 2024/howe/index.html | 2 +- 6 files changed, 13 insertions(+), 13 deletions(-) diff --git a/2024/burton/.entry.json b/2024/burton/.entry.json index ce1289e8c..e057b3d73 100644 --- a/2024/burton/.entry.json +++ b/2024/burton/.entry.json @@ -41,7 +41,7 @@ "file_path" : "deobfuscated.html", "inventory_order" : 100, "OK_to_edit" : false, - "display_as" : "markdown", + "display_as" : "html", "display_via_github" : true, "entry_text" : "about deobfuscation" }, @@ -57,8 +57,8 @@ "file_path" : "extra.html", "inventory_order" : 100, "OK_to_edit" : false, - "display_as" : "markdown", - "display_via_github" : true, + "display_as" : "html", + "display_via_github" : false, "entry_text" : "description of the extra files" }, { diff --git a/2024/burton/index.html b/2024/burton/index.html index a8112fcff..8df429747 100644 --- a/2024/burton/index.html +++ b/2024/burton/index.html @@ -881,7 +881,7 @@ due to the omissions noted above, but I am unaware of these.

  • prog.orig.c - original source code
  • deobfuscated.html - about deobfuscation
  • dict - 5-letter wordle dictionary
    • -
  • extra.html - description of the extra files
    • +
  • extra.html - description of the extra files
  • reveal.c - reveal wordle hints
  • try.sh - script to try entry
  • deobfuscated.c - deobfuscated source code
    • diff --git a/2024/ferguson1/.entry.json b/2024/ferguson1/.entry.json index 988feb902..ca541a256 100644 --- a/2024/ferguson1/.entry.json +++ b/2024/ferguson1/.entry.json @@ -97,8 +97,8 @@ "file_path" : "deobfuscation.html", "inventory_order" : 100, "OK_to_edit" : false, - "display_as" : "markdown", - "display_via_github" : true, + "display_as" : "html", + "display_via_github" : false, "entry_text" : "hints on how to deobfuscate" }, { @@ -129,8 +129,8 @@ "file_path" : "obfuscation.html", "inventory_order" : 100, "OK_to_edit" : false, - "display_as" : "markdown", - "display_via_github" : true, + "display_as" : "html", + "display_via_github" : false, "entry_text" : "obfuscation information" }, { diff --git a/2024/ferguson1/index.html b/2024/ferguson1/index.html index 5b52a389d..a06407596 100644 --- a/2024/ferguson1/index.html +++ b/2024/ferguson1/index.html @@ -3710,11 +3710,11 @@ helps you appreciate the careful design even more.bytecount.c - print each string with locations
  • byteread.c - prints out the strings without locations
  • bytetest.c - prints every string extracted from data
    • -
  • deobfuscation.html - hints on how to deobfuscate
    • +
  • deobfuscation.html - hints on how to deobfuscate
  • gotos.txt - text file showing all the line changes in a run
  • lencount.c - counts strings and reports longest one
  • mbcheck.c - show location of multibyte characters
    • -
  • obfuscation.html - obfuscation information
    • +
  • obfuscation.html - obfuscation information
  • printer.c - prints strings like the game does
  • try.sh - script to try entry
  • devil.png - Devil driving wagon
    • diff --git a/2024/howe/.entry.json b/2024/howe/.entry.json index 1a8e1f3f2..8a51725ac 100644 --- a/2024/howe/.entry.json +++ b/2024/howe/.entry.json @@ -41,8 +41,8 @@ "file_path" : "prog.html", "inventory_order" : 100, "OK_to_edit" : false, - "display_as" : "markdown", - "display_via_github" : true, + "display_as" : "html", + "display_via_github" : false, "entry_text" : "eh man page" }, { diff --git a/2024/howe/index.html b/2024/howe/index.html index c449f1777..1aa46a2b5 100644 --- a/2024/howe/index.html +++ b/2024/howe/index.html @@ -572,7 +572,7 @@ Location: CA - Canada
  • prog.c - entry source code
  • Makefile - entry Makefile
  • prog.orig.c - original source code
    • -
  • prog.html - eh man page
    • +
  • prog.html - eh man page
  • try.sh - script to try entry

    • Secondary files

    From c9800b86cb2b07a8c8f73caea62c5230b2add472 Mon Sep 17 00:00:00 2001 From: Cody Boone Ferguson <53008573+xexyl@users.noreply.github.com> Date: Tue, 5 Aug 2025 09:57:47 -0700 Subject: [PATCH 2/6] Add more stats to 2024/ferguson1 Line jump stats added, this time without function calls. --- 2024/ferguson1/README.md | 48 ++++++++++++++++++--------------- 2024/ferguson1/index.html | 47 +++++++++++++++++--------------- 2024/ferguson1/obfuscation.html | 18 ++++++------- 2024/ferguson1/obfuscation.md | 18 ++++++------- 4 files changed, 71 insertions(+), 60 deletions(-) diff --git a/2024/ferguson1/README.md b/2024/ferguson1/README.md index 15fd1fc4e..eaa28b6b1 100644 --- a/2024/ferguson1/README.md +++ b/2024/ferguson1/README.md @@ -56,10 +56,11 @@ inside this C code. :-) > Fun fact: after winning this, the author played the game in gdb from start to finish and not counting macros but counting all function calls (not libc functions just the few functions in prog.c), there were a total of **985** (!) -line jumps. The prog.c, counting `#include`s, `#define`s, functions and some -lines that have only braces, as well as 14 blank lines, has only 85 lines. A -very tiny fraction of the time a line might be repeated in a row ONCE but that -does not really matter. +line jumps. Skipping prog.c function calls and it's still **776** jumps! The +prog.c, if you remove `#include`s, blank lines, lines with just a brace and +lines that have only variables, has only 59 lines of code. A very tiny fraction +of the time a line might be repeated in a row ONCE but that does not really +matter. **NOTE**: I actually submitted two versions. This one is not encrypted. The encrypted one even encrypted emojis without having to decrypt them in order to @@ -3256,18 +3257,21 @@ Except on the Oregon Trail. I was right too: the entire game is worse, far far worse. After this won I did a full sequence. This is from start to finish and I include it for your amusement -(see [gotos.txt](gotos.txt)). Or horror. There are a few times where the line +(see [gotos.txt](gotos.txt) for the line changes including calls to prog.c +functions). Or horror. There are a few times where the line is the same but that only shows how very often the line changes. It is a total -of **985** (!) changes, counting function calls (i.e. each call to one of the few -functions is a jump); calls to the macros are not counted. +of **985** (!) changes, counting function calls, and **776** (!) excluding +function calls. Macros are not counted of course. -This is in a program that is **JUST 85 (!) lines**! A program that has only 85 lines -COUNTING the `#include`s, `#define`s, other functions and 14 blank lines that -jumps 985 times is astonishing. Of course that's not the only technique but the -title of the award and the judges' remarks are rather fitting as it is -diabolical to follow this code (and the theme of the game fits as well); the -[obfuscation.html](obfuscation.html) shows even more on this - and the other -things I did as well. +This program, if you remove blank lines and lines with just a brace, +`#include`s and only variables, has a mere 59 (!) lines. + +A program that has only 59 lines of code that jumps 985 (counting functions) or +776 (just in main()) times is astonishing. Of course that's not the +only technique but the title of the award and the judges' remarks are rather +fitting as it is diabolical to follow this code (and the theme of the game fits +as well); the [obfuscation.html](obfuscation.html) shows even more on this - and +the other things I did as well. > I have yet to see a single study that supported the supposition that GOTOs are harmful (I presume this is not because nobody has tried). Nonetheless, people @@ -3280,16 +3284,17 @@ said was missing. And it was about time. Not that it didn't happen before. But he was wrong. It is not about not trying. But even IF he WAS right, he -sure as hell is WRONG NOW. Anyone who thinks otherwise needs to try and debug +sure as hell is wrong NOW. Anyone who thinks otherwise needs to try and debug my program - or maintain it. Or write it. -It would have been SO MUCH EASIER if I did not use 134 `goto`s. Actually, even a +It would have been SO MUCH EASIER if I did not use 134 `goto`s (and I could have +fit more in). Actually, even a tiny portion of that would make it harder. Nobody, whether they're in their right mind or not, would WANT to maintain this, or something even close to it. Feel free to pass on judgement to me. I welcome it! You have to be mad and -embrace it to do this. I went full out and if I didn't have to do other things -(or felt like fewer events would be worth it) I would have done even more -`goto`s for this very reason. +embrace it to do this. I went full out and I could have fit more `goto`s in: not +only is the iocccsize not 2503 but I could have removed some events if I really +wanted more `goto`s. Even flex/bison code, which as far as I am aware uses FAR fewer `goto`s, is notorious for `goto`s and is quite hard to follow. It would be a nightmare to @@ -3421,9 +3426,10 @@ the degree I have taken it in this program, it demonstrates why you should avoid No matter how many you have, UNLESS IT'S 0, it makes it hard to maintain and ensure that the code is correct. So how did I actually manage doing exactly that? Very carefully - and I nearly lost my mind doing it. I will not make any -judgement on anyone else who uses them. +judgement on anyone else who uses them, although I will talk about the notion +that they aren't harmful, mostly to show just how extreme this program went. -Anyway, I am even reminded of Apple's **SINGLE** misplaced `goto` that caused a +Anyway, I am reminded of Apple's **SINGLE** misplaced `goto` that caused a **SECURITY HOLE** (CVE-2014-1266): . That's all it takes: **JUST ONE `goto` led to a CVE**! diff --git a/2024/ferguson1/index.html b/2024/ferguson1/index.html index a06407596..24da10042 100644 --- a/2024/ferguson1/index.html +++ b/2024/ferguson1/index.html @@ -499,10 +499,11 @@ inside this C code. :-)

    Fun fact: after winning this, the author played the game in gdb from start to finish and not counting macros but counting all function calls (not libc functions just the few functions in prog.c), there were a total of 985 (!) -line jumps. The prog.c, counting #includes, #defines, functions and some -lines that have only braces, as well as 14 blank lines, has only 85 lines. A -very tiny fraction of the time a line might be repeated in a row ONCE but that -does not really matter.

    +line jumps. Skipping prog.c function calls and it’s still 776 jumps! The +prog.c, if you remove #includes, blank lines, lines with just a brace and +lines that have only variables, has only 59 lines of code. A very tiny fraction +of the time a line might be repeated in a row ONCE but that does not really +matter.

    NOTE: I actually submitted two versions. This one is not encrypted. The encrypted one even encrypted emojis without having to decrypt them in order to @@ -3090,17 +3091,19 @@ I’m a dragon. I’m not a dragon. I have a secret for you: dragons don’t exi Except on the Oregon Trail.

    I was right too: the entire game is worse, far far worse. After this won I did a full sequence. This is from start to finish and I include it for your amusement -(see gotos.txt). Or horror. There are a few times where the line +(see gotos.txt for the line changes including calls to prog.c +functions). Or horror. There are a few times where the line is the same but that only shows how very often the line changes. It is a total -of 985 (!) changes, counting function calls (i.e. each call to one of the few -functions is a jump); calls to the macros are not counted.

    -

    This is in a program that is JUST 85 (!) lines! A program that has only 85 lines -COUNTING the #includes, #defines, other functions and 14 blank lines that -jumps 985 times is astonishing. Of course that’s not the only technique but the -title of the award and the judges’ remarks are rather fitting as it is -diabolical to follow this code (and the theme of the game fits as well); the -obfuscation.html shows even more on this - and the other -things I did as well.

    +of 985 (!) changes, counting function calls, and 776 (!) excluding +function calls. Macros are not counted of course.

    +

    This program, if you remove blank lines and lines with just a brace, +#includes and only variables, has a mere 59 (!) lines.

    +

    A program that has only 59 lines of code that jumps 985 (counting functions) or +776 (just in main()) times is astonishing. Of course that’s not the +only technique but the title of the award and the judges’ remarks are rather +fitting as it is diabolical to follow this code (and the theme of the game fits +as well); the obfuscation.html shows even more on this - and +the other things I did as well.

    I have yet to see a single study that supported the supposition that GOTOs are harmful (I presume this is not because nobody has tried). Nonetheless, people @@ -3112,15 +3115,16 @@ dismiss any statement opposing it.

    said was missing. And it was about time. Not that it didn’t happen before. But he was wrong.

    It is not about not trying. But even IF he WAS right, he -sure as hell is WRONG NOW. Anyone who thinks otherwise needs to try and debug +sure as hell is wrong NOW. Anyone who thinks otherwise needs to try and debug my program - or maintain it. Or write it.

    -

    It would have been SO MUCH EASIER if I did not use 134 gotos. Actually, even a +

    It would have been SO MUCH EASIER if I did not use 134 gotos (and I could have +fit more in). Actually, even a tiny portion of that would make it harder. Nobody, whether they’re in their right mind or not, would WANT to maintain this, or something even close to it. Feel free to pass on judgement to me. I welcome it! You have to be mad and -embrace it to do this. I went full out and if I didn’t have to do other things -(or felt like fewer events would be worth it) I would have done even more -gotos for this very reason.

    +embrace it to do this. I went full out and I could have fit more gotos in: not +only is the iocccsize not 2503 but I could have removed some events if I really +wanted more gotos.

    Even flex/bison code, which as far as I am aware uses FAR fewer gotos, is notorious for gotos and is quite hard to follow. It would be a nightmare to try and maintain without the .l/.y source files.

    @@ -3228,8 +3232,9 @@ the degree I have taken it in this program, it demonstrates why you should avoid

    No matter how many you have, UNLESS IT’S 0, it makes it hard to maintain and ensure that the code is correct. So how did I actually manage doing exactly that? Very carefully - and I nearly lost my mind doing it. I will not make any -judgement on anyone else who uses them.

    -

    Anyway, I am even reminded of Apple’s SINGLE misplaced goto that caused a +judgement on anyone else who uses them, although I will talk about the notion +that they aren’t harmful, mostly to show just how extreme this program went.

    +

    Anyway, I am reminded of Apple’s SINGLE misplaced goto that caused a SECURITY HOLE (CVE-2014-1266): https://www.blackduck.com/blog/understanding-apple-goto-fail-vulnerability-2.html. That’s all it takes: JUST ONE goto led to a CVE!

    diff --git a/2024/ferguson1/obfuscation.html b/2024/ferguson1/obfuscation.html index 166e508b2..17a5eb4cf 100644 --- a/2024/ferguson1/obfuscation.html +++ b/2024/ferguson1/obfuscation.html @@ -510,16 +510,16 @@ YES I think it’s HILARIOUS. But if it was not for the IOCCC… Well, as I mention in my remarks above, EVEN ONE IS TOO MANY in real code.

    I dare you to run the program in a debugger from start to finish to see how many -line jumps there truly are. After I won I did it once: in a program with just 85 -lines (14 blank, some with just a brace, #includes, #defines included) there -were a total of 985 line changes (a tiny tiny fraction had the same line number -repeated once). I rarely went to the fort and I only hunted once (I might not -have hunted at all). This is obscene.

    +line jumps there truly are. After I won I did it once: removing the #includes, +blank lines, lines with only variables and lines with just braces (i.e. only +lines of code) the program has just 59 lines and in a single run there were a +total of 985 (!) line changes, counting function calls. In main() itself +the line changed a total of 776 (!) times!

    The best (or worst, depending on how you look at it :-) ) part is this works. As -I note in those concluding remarks, a company actually introduced a security -hole from ONE goto. Yet I have 116/134 and it actually works? That is surely -obscene. And beautiful.

    -

    Oh and BTW: it appears that hines is a bit confused about my submission, +I note in those concluding remarks, a famous company +actually introduced a security hole from ONE goto. Yet I have 116/134 and it +actually works? That is surely obscene. And beautiful.

    +

    Oh and BTW: it appears that hines is a bit confused about my entry, though I’m not really sure why. In any case, I not only have dethroned hines (sorry …but also not sorry!) but I have, as noted already, beaten the original BASIC game by 7 more gotos at 116 before the cpp and 25 MORE after the diff --git a/2024/ferguson1/obfuscation.md b/2024/ferguson1/obfuscation.md index d768cdd41..103c7868f 100644 --- a/2024/ferguson1/obfuscation.md +++ b/2024/ferguson1/obfuscation.md @@ -68,18 +68,18 @@ mention in my [remarks above](#devil), EVEN ONE IS TOO MANY in real code. I dare you to run the program in a debugger from start to finish to see how many -line jumps there truly are. After I won I did it once: in a program with just 85 -lines (14 blank, some with just a brace, `#include`s, `#define`s included) there -were a total of 985 line changes (a tiny tiny fraction had the same line number -repeated once). I rarely went to the fort and I only hunted once (I might not -have hunted at all). This is obscene. +line jumps there truly are. After I won I did it once: removing the `#include`s, +blank lines, lines with only variables and lines with just braces (i.e. only +lines of code) the program has just 59 lines and in a single run there were a +total of **985** (!) line changes, counting function calls. In `main()` itself +the line changed a total of **776** (!) times! The best (or worst, depending on how you look at it :-) ) part is this works. As -I note in those concluding remarks, a company actually introduced a security -hole from ONE `goto`. Yet I have 116/134 and it actually works? That is surely -obscene. And beautiful. +I note in those concluding remarks, a [famous company](https://www.apple.com) +actually introduced a security hole from ONE `goto`. Yet I have 116/134 and it +actually works? That is surely obscene. And beautiful. -Oh and BTW: it appears that `hines` is a bit confused about my submission, +Oh and BTW: it appears that `hines` is a bit confused about my entry, though I'm not really sure why. In any case, I not only have dethroned `hines` (sorry ...but also not sorry!) but I have, as noted already, beaten the original BASIC game by **7** more `goto`s at 116 before the cpp and **25 MORE** after the From 531be8942cefd514cae28ef5c095f5fc36cf1f14 Mon Sep 17 00:00:00 2001 From: Landon Curt Noll Date: Tue, 5 Aug 2025 15:52:55 -0700 Subject: [PATCH 3/6] update sitemap based on previous edits --- sitemap.xml | 32 ++++++++++++++++---------------- 1 file changed, 16 insertions(+), 16 deletions(-) diff --git a/sitemap.xml b/sitemap.xml index 4aab5f5fd..2ba2ac379 100644 --- a/sitemap.xml +++ b/sitemap.xml @@ -9146,7 +9146,7 @@ https://www.ioccc.org/2012/omoikane/index.html - 2025-07-26T18:44:07+00:00 + 2025-08-05T07:32:55+00:00 https://www.ioccc.org/2012/omoikane/Makefile @@ -14346,7 +14346,7 @@ https://www.ioccc.org/2024/burton/index.html - 2025-08-04T19:21:50+00:00 + 2025-08-05T22:50:30+00:00 https://www.ioccc.org/2024/burton/Makefile @@ -14442,7 +14442,7 @@ https://www.ioccc.org/2024/cable1/index.html - 2025-08-03T19:39:58+00:00 + 2025-08-04T20:31:45+00:00 https://www.ioccc.org/2024/cable1/Makefile @@ -14458,7 +14458,7 @@ https://www.ioccc.org/2024/cable1/README.md - 2025-08-03T19:39:30+00:00 + 2025-08-04T20:31:45+00:00 https://www.ioccc.org/2024/cable1/try.sh @@ -14754,7 +14754,7 @@ https://www.ioccc.org/2024/ferguson1/index.html - 2025-08-04T19:03:08+00:00 + 2025-08-05T22:50:30+00:00 https://www.ioccc.org/2024/ferguson1/ioccc.jpg @@ -14778,11 +14778,11 @@ https://www.ioccc.org/2024/ferguson1/obfuscation.html - 2025-08-04T19:03:08+00:00 + 2025-08-05T22:50:30+00:00 https://www.ioccc.org/2024/ferguson1/obfuscation.md - 2025-08-04T19:03:08+00:00 + 2025-08-05T22:50:30+00:00 https://www.ioccc.org/2024/ferguson1/printer.c @@ -14802,7 +14802,7 @@ https://www.ioccc.org/2024/ferguson1/README.md - 2025-08-04T19:03:08+00:00 + 2025-08-05T22:50:30+00:00 https://www.ioccc.org/2024/ferguson1/spaghetti.png @@ -14850,7 +14850,7 @@ https://www.ioccc.org/2024/ferguson2/index.html - 2025-08-04T19:03:08+00:00 + 2025-08-04T20:31:45+00:00 https://www.ioccc.org/2024/ferguson2/Makefile @@ -14886,7 +14886,7 @@ https://www.ioccc.org/2024/ferguson2/README.md - 2025-08-03T19:51:15+00:00 + 2025-08-04T20:31:45+00:00 https://www.ioccc.org/2024/ferguson2/sam.jpg @@ -14910,7 +14910,7 @@ https://www.ioccc.org/2024/howe/index.html - 2025-08-03T18:29:13+00:00 + 2025-08-05T22:50:30+00:00 https://www.ioccc.org/2024/howe/Makefile @@ -15158,7 +15158,7 @@ https://www.ioccc.org/2024/kurdyukov4/prog.c - 2025-07-05T06:08:05+00:00 + 2025-08-05T22:50:30+00:00 https://www.ioccc.org/2024/kurdyukov4/prog.orig.c @@ -15166,7 +15166,7 @@ https://www.ioccc.org/2024/kurdyukov4/README.md - 2025-07-22T18:05:48+00:00 + 2025-08-05T22:50:30+00:00 https://www.ioccc.org/2024/kurdyukov4/try.sh @@ -16722,11 +16722,11 @@ https://www.ioccc.org/bugs.html - 2025-07-26T20:09:50+00:00 + 2025-08-05T22:51:10+00:00 https://www.ioccc.org/bugs.md - 2025-07-26T20:09:50+00:00 + 2025-08-05T22:51:10+00:00 https://www.ioccc.org/CODE_OF_CONDUCT.html @@ -16926,7 +16926,7 @@ https://www.ioccc.org/status.html - 2025-08-04T19:22:58+00:00 + 2025-08-05T22:47:21+00:00 https://www.ioccc.org/status.json From d7bd85dd6de43e457a6af4fb1c3dc223423ba10a Mon Sep 17 00:00:00 2001 From: Cody Boone Ferguson <53008573+xexyl@users.noreply.github.com> Date: Wed, 6 Aug 2025 04:45:41 -0700 Subject: [PATCH 4/6] Typos fixes in 2024/index.html + add show URL Typos fixed in 2024/index.html. Show URL added. This commit also adds the time (how long in the show, not the clock time) the source code was pushed to the GitHub repo and the total length of the show. --- 2024/README.md | 68 +++++++++++++++++++++++++++---------------------- 2024/index.html | 67 +++++++++++++++++++++++++++--------------------- 2 files changed, 76 insertions(+), 59 deletions(-) diff --git a/2024/README.md b/2024/README.md index a688210ef..83b0d37ed 100644 --- a/2024/README.md +++ b/2024/README.md @@ -39,15 +39,20 @@ The **major motivation** for the above was to: On the last point, for **IOCCC28** the Judging started on **2025-06-05 04:03:02.010099 UTC** and then the winners were selected by the [IOCCC Judges](../judges.html) on **2025-07-07 20:05:07.000000 UTC**: -* Winners were announced during a live the [Our Favorite Universe](https://www.youtube.com/@OurFavoriteUniverse) YouTube Channel that started on **2025-08-02 18:00:00.000000 UTC** +* Winners were announced during a live show that started on **2025-08-02 18:00:00.000000 UTC** + on the [Our Favorite Universe](https://www.youtube.com/@OurFavoriteUniverse) + YouTube Channel. -* Near the end of the 2 hour XXX-add-show-URL-here-XXX YouTube show, the **source code** of the [IOCCC28 winning entries](#inventory) was published on [IOCCC GitHub winner repo](https://github.com/ioccc-src/winner) and on the [Official IOCCC website](../index.html). +* At about 03h:42m:03s mark in the 04h:30m:35s [YouTube +show](https://www.youtube.com/live/UDzGwTalVAc), the **source code** of the +[IOCCC28 winning entries](#inventory) was published on [IOCCC GitHub winner +repo](https://github.com/ioccc-src/winner) and on the [Official IOCCC +website](../index.html). **No longer will there be many months** between when the winners are announced and their source code is made available. For **IOCCC28** the time was **less than 2 hours**. :-) - ### Increased submission quantity and quality The submissions to **IOCCC28** were remarkable when compared with previous contests, in both the @@ -55,16 +60,16 @@ The submissions to **IOCCC28** were remarkable when compared with previous conte was more challenging and required greater effort. Thankfully due to the above mentioned improvements, the judging process **took only 33 days**. Under the previous system it **would have taken much longer**! -One thing that began to emerge after we exits the early rounds of judging and entered the middle rounds +One thing that began to emerge after we exited the early rounds of judging and entered the middle rounds of judging was that we were very likely to have more winning entries than in previous contests. -Even so, the final rounds of judging required more rounds and tool longer than in any previous IOCCC. +Even so, the final rounds of judging required more rounds and took longer than any previous IOCCC. At the end of the final round of the final rounds of judging, we had a record **23 winners of IOCCC28**, eclipsing the record of 15 winners! While we suspect that the 4 year gap between **IOCCC27** and **IOCCC28** allowed people extra time to improve their submissions, we also believe that people -submitting to the IOCCC have become more adept in adept in obfuscation and have +submitting to the IOCCC have become more adept in obfuscation and have become more skilled in the programming in the C language. @@ -82,14 +87,15 @@ was the first size increase in over 10 years. Given the quality of submissions that were well under the limit, we do **NOT** expect to change the [Rule 2 size limit](../next/rules.html#rule2) for **at least another 10 years** (and likely longer). -**IMPORTANT HINT**: Only 3 of 23 the **IOCCC28 winners** came close to the [Rule 2 size limit](../next/rules.html#rule2). -Large code size isn't everything. :-) Those submitting to future contents should -**take a careful note** of that fact. +**IMPORTANT HINT**: Only 3 of the 23 **IOCCC28 winners** came close to the [Rule +2 size limit](../next/rules.html#rule2). Large code size isn't everything. :-) +Those submitting to future contents should **take a careful note** of that fact. ### Rules and Guidelines for this contest -Here are the final versions of the IOCCC rules and guidelines that were in effect for this contest: +Here are the final versions of the IOCCC rules and guidelines that were in +effect for this contest: * [2024 rules](rules.html) version **28.30 2025-03-03** * [2024 guidelines](guidelines.html) version **28.47 2025-03-15** @@ -142,7 +148,7 @@ into the code's obfuscation. :-) * [2024/howe](howe/index.html) "_Eh_"? The source code, with its UTF-8 conforming accent gives you a -polite editor that is more functional an `ed(1)`. +polite editor that is more functional than `ed(1)`. We invite you to use the program to view the UTF-8 fun in the [2024/howe/prog.c source code](%%REPO_URL%%/2024/howe/prog.c). @@ -165,7 +171,7 @@ different hex digits value. Then feed the MD5 hash of the The [2024/endoh1/try.sh](%%REPO_URL%%/2024/endoh1/try.sh) will carry you on a journey that tests your patience as well as the patience of the C-preprocessor. -Building a 8x8 image requires order of 20 seconds of C-preprocessor +Building a 8x8 image requires an order of 20 seconds of C-preprocessor time, when running 6 jobs on 4 CPU cores in parallel. Unfortunately, with such a tiny image, it is hard to appreciate the image being rendered. @@ -185,8 +191,8 @@ will be given an image with a reasonable amount of detail to appreciate what is being rendered. One fun aspect of the [2024/endoh1/prog.c source code](%%REPO_URL%%/2024/endoh1/prog.c) -is that when it is compiled an executed, the program outputs C code. -That C code, call it `rt.c` will fail to compile! But that is OK because the C-preprocessor +is that when it is compiled and executed, the program outputs C code. +That C code, called `rt.c`, will fail to compile! But that is OK because the C-preprocessor has enough work to do without bothering the C compiler. :-) We plan to recognise those who report that they [rendered a new record sized image](endoh1/index.html#larger). @@ -204,7 +210,7 @@ This won the "**Prize in ℤ₃**", but what does that mean? Well, the "_double-struck Z_" is **NOT** a reference to a set of integers, nor is the "_double-struck Z subscript 3_" a reference to a ring of 3-adic integers. Instead, it is a reference to the 3rd version of a -certain [virtual machine](https://en.wikipedia.org/wiki/Z-machine). +[certain virtual machine](https://en.wikipedia.org/wiki/Z-machine). If you use the [2024/mills/try.sh](%%REPO_URL%%/2024/mills/try.sh) script, you will first be given an opportunity to view the [2024/mills/prog.c source code](%%REPO_URL%%/2024/mills/prog.c). @@ -218,7 +224,7 @@ reading/navigating the twisty mazes of this source code! :-) As you study the [2024/codemeow/prog.c source code](%%REPO_URL%%/2024/codemeow/prog.c), try not to lose track of the forest of obfuscation while tracking down the execution path trees. -We think this code will "grow on you" as the C expression goes just a compiled C code "_grows on parse trees_". :-) +We think this code will "grow on you" as the C expression goes just as compiled C code "_grows on parse trees_". :-) * [2024/kurdyukov2](kurdyukov2/index.html) @@ -235,13 +241,13 @@ you run this code: let alone when your try to figure out how the author was able encode the virtual machine in under **2.5K bytes** of [prog.c source code](%%REPO_URL%%/2024/kurdyukov3/prog.c)! **NOTE**: The implementation runs without sound or mouse -input. You will need reply on your keyboard skills. The +input. You will need to rely on your keyboard skills. The [2024/kurdyukov3/try.sh](%%REPO_URL%%/2024/kurdyukov3/try.sh) demonstration script will give you some useful keyboard hints. * [2024/cable2](cable2/index.html) -To those who follow the concept of "_seeing is believing_" will very +Those who follow the concept of "_seeing is believing_" will very likely be "_deceived_" when they try to see the source in terminal window: ``` @@ -249,11 +255,11 @@ likely be "_deceived_" when they try to see the source in terminal window: ``` Viewing the [prog.c source code](%%REPO_URL%%/2024/cable2/prog.c) in most editors -might suggest that the is something fishy 🐠 with the code. +might suggest that there is something fishy 🐠 with the code. * [2024/macke](macke/index.html) -Have you ever wondered would what would happen if you recursively removed +Have you ever wondered what would would happen if you recursively removed files starting from the root directory? Are you curious what happens when you launch a [fork bomb](https://en.wikipedia.org/wiki/Fork_bomb)? You can safely give those and other scenarios under this virtual machine. @@ -291,15 +297,15 @@ by computing the output of each gate in a loop, effectively running the CPU and ### Remarks on some of submissions that did not win -* Depending on the address of a variable, as not all platforms support -[ASLR](https://en.wikipedia.org/wiki/Address_space_layout_randomization), -as the single source of pseudo-randomness isn't a good idea. It's -much better to mix in other sources of variability (e.g. time, process +* Depending on the address of a variable as the single source of +pseudo-randomness isn't a good idea, as not all platforms support +[ASLR](https://en.wikipedia.org/wiki/Address_space_layout_randomization). +It's much better to mix in other sources of variability (e.g. time, process ID, etc.) so that subsequent runs will behave differently. * If a submission's obfuscation strongly resembles a past IOCCC winning entry, and the submission's obfuscation is mainly in the C code source, -then the submission likely to not make it into the final rounds of judging. +then the submission is likely to not make it into the final rounds of judging. * When working with modern C compilers, it's crucial to explicitly declare variable and function types. Don't assume they'll @@ -319,8 +325,9 @@ might not be the most innovative approach. C code that implements the mathematics is well obfuscated. * Just a friendly reminder that before you upload your submissions, -uncompress the compressed tarball into a different directory. This way, -you can be sure you didn't miss uploading any important files! +uncompress the compressed tarball into a different directory and verify +everything is in order. This way, you can be sure you didn't miss uploading any +important files! * Using a lot of goto statements to make your code harder to understand might not help it pass the final rounds of judging. @@ -339,7 +346,7 @@ submission. If you think this happened with your submission, consider submitting an enhanced version to the next IOCCC. **PLEASE DO NOT** give up hope! There are some submissions that have been -submitted with revisions, multiple times before rising to the level of +submitted with revisions multiple times before rising to the level of a winning IOCCC entry. You might also want to try with a different type of submission altogether for the next IOCCC. @@ -353,14 +360,15 @@ Some C compilers aren't as great as they could be. If yours isn't working well, you might want to try compiling with an updated version of clang and/or gcc instead. -If you encounter problems in compiling and/or running the winning entries, see the FAQ on: +If you encounter problems in compiling and/or running the winning entries, see +the FAQs on: * [Compiling IOCCC entries](../faq.html#compiling) * [IOCCC entry dependencies](../faq.html#dependencies) * [Problems compiling entries](../faq.html#compile_problems) * [Running IOCCC entries](../faq.html#running_entries) -For additional information on how to submit fixes, see the FAQ on: +For additional information on how to submit fixes, see the FAQs on: * [How to submit a fix](../faq.html#fix_an_entry) - how to submit a fix to an entry * [Update author information](../faq.html#fix_author) - how to correct or update an IOCCC author's information diff --git a/2024/index.html b/2024/index.html index 5f4f54ace..ac2a75322 100644 --- a/2024/index.html +++ b/2024/index.html @@ -484,8 +484,14 @@ the mkiocccentry toolkit

    On the last point, for IOCCC28 the Judging started on 2025-06-05 04:03:02.010099 UTC and then the winners were selected by the IOCCC Judges on 2025-07-07 20:05:07.000000 UTC:

    No longer will there be many months between when the winners are announced and their source code is made available. For IOCCC28 @@ -495,14 +501,14 @@ the time was less than 2 hours. :-)

    increased quantity and quality of the submissions. As a result the judging process for IOCCC28 was more challenging and required greater effort. Thankfully due to the above mentioned improvements, the judging process took only 33 days. Under the previous system it would have taken much longer!

    -

    One thing that began to emerge after we exits the early rounds of judging and entered the middle rounds +

    One thing that began to emerge after we exited the early rounds of judging and entered the middle rounds of judging was that we were very likely to have more winning entries than in previous contests. -Even so, the final rounds of judging required more rounds and tool longer than in any previous IOCCC.

    +Even so, the final rounds of judging required more rounds and took longer than any previous IOCCC.

    At the end of the final round of the final rounds of judging, we had a record 23 winners of IOCCC28, eclipsing the record of 15 winners!

    While we suspect that the 4 year gap between IOCCC27 and IOCCC28 allowed people extra time to improve their submissions, we also believe that people -submitting to the IOCCC have become more adept in adept in obfuscation and have +submitting to the IOCCC have become more adept in obfuscation and have become more skilled in the programming in the C language.

    Code size and Rule 2

    We were pleased to observe that while the IOCCC size limit @@ -515,11 +521,12 @@ small and medium sized submissions. Half of the IOCCC28 winners was the first size increase in over 10 years. Given the quality of submissions we received that were well under the limit, we do NOT expect to change the Rule 2 size limit for at least another 10 years (and likely longer).

    -

    IMPORTANT HINT: Only 3 of 23 the IOCCC28 winners came close to the Rule 2 size limit. -Large code size isn’t everything. :-) Those submitting to future contents should -take a careful note of that fact.

    +

    IMPORTANT HINT: Only 3 of the 23 IOCCC28 winners came close to the Rule +2 size limit. Large code size isn’t everything. :-) +Those submitting to future contents should take a careful note of that fact.

    Rules and Guidelines for this contest

    -

    Here are the final versions of the IOCCC rules and guidelines that were in effect for this contest:

    +

    Here are the final versions of the IOCCC rules and guidelines that were in +effect for this contest:

    “Eh”? The source code, with its UTF-8 conforming accent gives you a -polite editor that is more functional an ed(1).

    +polite editor that is more functional than ed(1).

    We invite you to use the program to view the UTF-8 fun in the 2024/howe/prog.c source code.

    HINT to emacs users: type Q or press CTRL+C to exit. 🤓

    @@ -582,7 +589,7 @@ different hex digits value. Then feed the MD5 hash of the

    The 2024/endoh1/try.sh will carry you on a journey that tests your patience as well as the patience of the C-preprocessor.

    -

    Building a 8x8 image requires order of 20 seconds of C-preprocessor +

    Building a 8x8 image requires an order of 20 seconds of C-preprocessor time, when running 6 jobs on 4 CPU cores in parallel. Unfortunately, with such a tiny image, it is hard to appreciate the image being rendered.

    So you might try building a 32x32 form of the image, invoking the @@ -598,8 +605,8 @@ the C-preprocessor 262144 times over a period of about 23.5 hours, you will be given an image with a reasonable amount of detail to appreciate what is being rendered.

    One fun aspect of the 2024/endoh1/prog.c source code -is that when it is compiled an executed, the program outputs C code. -That C code, call it rt.c will fail to compile! But that is OK because the C-preprocessor +is that when it is compiled and executed, the program outputs C code. +That C code, called rt.c, will fail to compile! But that is OK because the C-preprocessor has enough work to do without bothering the C compiler. :-)

    We plan to recognise those who report that they rendered a new record sized image.

    As you study the 2024/codemeow/prog.c source code, try not to lose track of the forest of obfuscation while tracking down the execution path trees.

    -

    We think this code will “grow on you” as the C expression goes just a compiled C code “grows on parse trees”. :-)

    +

    We think this code will “grow on you” as the C expression goes just as compiled C code “grows on parse trees”. :-)

    @@ -641,21 +648,21 @@ then you might be able to see how the code words.

    you run this code: let alone when your try to figure out how the author was able to encode the virtual machine in under 2.5K bytes of prog.c source code!

    NOTE: The implementation runs without sound or mouse -input. You will need reply on your keyboard skills. The +input. You will need to rely on your keyboard skills. The 2024/kurdyukov3/try.sh demonstration script will give you some useful keyboard hints.

    -

    To those who follow the concept of “seeing is believing” will very +

    Those who follow the concept of “seeing is believing” will very likely be “deceived” when they try to see the source in terminal window:

        cat 2024/cable2/prog.c

    Viewing the prog.c source code in most editors -might suggest that the is something fishy 🐠 with the code.

    +might suggest that there is something fishy 🐠 with the code.

    -

    Have you ever wondered would what would happen if you recursively removed +

    Have you ever wondered what would would happen if you recursively removed files starting from the root directory? Are you curious what happens when you launch a fork bomb? You can safely give those and other scenarios under this virtual machine.

    @@ -688,14 +695,14 @@ emulating the entire by computing the output of each gate in a loop, effectively running the CPU and associated RAM/ROM chips!

    Remarks on some of submissions that did not win

    @@ -724,7 +732,7 @@ winning IOCCC entry, only to be beaten by a similar, but slightly better submission. If you think this happened with your submission, consider submitting an enhanced version to the next IOCCC.

    PLEASE DO NOT give up hope! There are some submissions that have been -submitted with revisions, multiple times before rising to the level of +submitted with revisions multiple times before rising to the level of a winning IOCCC entry. You might also want to try with a different type of submission altogether for the next IOCCC.

    If you’re not planning to improve and resubmit your non-winning entry @@ -733,14 +741,15 @@ for the next IOCCC, you’re welcome to publish it.

    Some C compilers aren’t as great as they could be. If yours isn’t working well, you might want to try compiling with an updated version of clang and/or gcc instead.

    -

    If you encounter problems in compiling and/or running the winning entries, see the FAQ on:

    +

    If you encounter problems in compiling and/or running the winning entries, see +the FAQs on:

    -

    For additional information on how to submit fixes, see the FAQ on:

    +

    For additional information on how to submit fixes, see the FAQs on:

    Secondary files

    From 5d9ad2012a2294f5d894415e05a6f9fbb6fd9fe1 Mon Sep 17 00:00:00 2001 From: Cody Boone Ferguson <53008573+xexyl@users.noreply.github.com> Date: Wed, 6 Aug 2025 11:00:02 -0700 Subject: [PATCH 6/6] Add maxed out goto (149) version to 2024/ferguson1 For practical reasons (and to make the judges weep and curse slightly less) I only submitted code that only had 134 gotos. I'm a horrible monster, I know, but I have decided to present this alt version I have which takes the 134 gotos to 149 and which still fits in rule 2 limits. If I am going to ruin goto I might as well do it properly, despite Landon telling me that the 134 might be called near limitless. Now it is limitless. Some of the very few remaining blocks of code that were where they belong were moved away from their proper place but other changes were made too. Added gotos.c.txt - kind of like the judges' video where it shows all the gotos only here it is just a text file of only the gotos (after clang-format like they had). This is of prog.c, not prog.goto.max.c. Renamed gotos.txt to jumps.txt as it's not just gotos (though most of it is). Updated .gitignore and Makefile. Updated .entry.json and rebuilt index.html as well as obfuscation.html (obfuscation.md was also updated). --- 2024/ferguson1/.entry.json | 20 +++- 2024/ferguson1/.gitignore | 3 + 2024/ferguson1/Makefile | 24 ++++- 2024/ferguson1/README.md | 23 ++-- 2024/ferguson1/gotos.c.txt | 134 ++++++++++++++++++++++++ 2024/ferguson1/index.html | 26 +++-- 2024/ferguson1/{gotos.txt => jumps.txt} | 0 2024/ferguson1/obfuscation.html | 5 +- 2024/ferguson1/obfuscation.md | 5 +- 2024/ferguson1/prog.goto.max.c | 85 +++++++++++++++ 10 files changed, 304 insertions(+), 21 deletions(-) create mode 100644 2024/ferguson1/gotos.c.txt rename 2024/ferguson1/{gotos.txt => jumps.txt} (100%) create mode 100644 2024/ferguson1/prog.goto.max.c diff --git a/2024/ferguson1/.entry.json b/2024/ferguson1/.entry.json index ca541a256..8957547e4 100644 --- a/2024/ferguson1/.entry.json +++ b/2024/ferguson1/.entry.json @@ -37,6 +37,14 @@ "display_via_github" : true, "entry_text" : "alternate source code" }, + { + "file_path" : "prog.goto.max.c", + "inventory_order" : 40, + "OK_to_edit" : true, + "display_as" : "c", + "display_via_github" : true, + "entry_text" : "entry source code with maxed out gotos" + }, { "file_path" : "prog.orig.c", "inventory_order" : 50, @@ -102,12 +110,20 @@ "entry_text" : "hints on how to deobfuscate" }, { - "file_path" : "gotos.txt", + "file_path" : "gotos.c.txt", "inventory_order" : 100, "OK_to_edit" : true, "display_as" : "text", "display_via_github" : true, - "entry_text" : "text file showing all the line changes in a run" + "entry_text" : "text file showing only the gotos in the entry code" + }, + { + "file_path" : "jumps.txt", + "inventory_order" : 100, + "OK_to_edit" : true, + "display_as" : "text", + "display_via_github" : true, + "entry_text" : "text file showing all the line changes in a single run" }, { "file_path" : "lencount.c", diff --git a/2024/ferguson1/.gitignore b/2024/ferguson1/.gitignore index e04469a91..551096ebd 100644 --- a/2024/ferguson1/.gitignore +++ b/2024/ferguson1/.gitignore @@ -20,4 +20,7 @@ printer prog.alt.asc prog.alt.scrnshot prog.asc +prog.goto.max +prog.goto.max.asc +prog.goto.max.scrnshot prog.scrnshot diff --git a/2024/ferguson1/Makefile b/2024/ferguson1/Makefile index 234d2d9ae..1528d00f3 100644 --- a/2024/ferguson1/Makefile +++ b/2024/ferguson1/Makefile @@ -154,8 +154,10 @@ TARGET= ${PROG} ${PROG}.asc ${PROG}.scrnshot # .alt is as above more events # -ALT_OBJ= ${PROG}.alt.o ${PROG}.alt.asc.o ${PROG}.alt.scrnshot.o -ALT_TARGET= ${PROG}.alt ${PROG}.alt.asc ${PROG}.alt.scrnshot +ALT_OBJ= ${PROG}.alt.o ${PROG}.alt.asc.o ${PROG}.alt.scrnshot.o ${PROG}.goto.max.o \ + ${PROG}.goto.max.asc.o ${PROG}.goto.max.scrnshot.o +ALT_TARGET= ${PROG}.alt ${PROG}.alt.asc ${PROG}.alt.scrnshot ${PROG}.goto.max \ + ${PROG}.goto.max.asc ${PROG}.goto.max.scrnshot # list any data files supplied with the submission # @@ -350,12 +352,30 @@ ${PROG}.alt.asc: ${PROG}.alt.c ${MAKE} padding ${CC} ${CFLAGS} -DDATA='"data.asc"' ${PROG}.alt.c -o $@ ${LDFLAGS} +# goto maxed out - regular data file +# +${PROG}.goto.max: ${PROG}.goto.max.c + ${MAKE} padding + ${CC} ${CFLAGS} -DDATA='"data"' ${PROG}.goto.max.c -o $@ ${LDFLAGS} + +# goto maxed out - ASCII only data file +# +${PROG}.goto.max.asc: ${PROG}.goto.max.c + ${MAKE} padding + ${CC} ${CFLAGS} -DDATA='"data.asc"' ${PROG}.goto.max.c -o $@ ${LDFLAGS} + # screenshot friendly version of alt code # ${PROG}.alt.scrnshot: ${PROG}.alt.c ${MAKE} padding ${CC} ${CFLAGS} -DDATA='"data.scrnshot"' ${PROG}.alt.c -o $@ ${LDFLAGS} +# goto maxed out - screenshot friendly version +# +${PROG}.goto.max.scrnshot: ${PROG}.goto.max.c + ${MAKE} padding + ${CC} ${CFLAGS} -DDATA='"data.scrnshot"' ${PROG}.goto.max.c -o $@ ${LDFLAGS} + # data files # data: ${DATA} diff --git a/2024/ferguson1/README.md b/2024/ferguson1/README.md index eaa28b6b1..c8622d77f 100644 --- a/2024/ferguson1/README.md +++ b/2024/ferguson1/README.md @@ -2455,11 +2455,15 @@ really does not seem to be dead (it's quite sneaky). I could be wrong on whether this is one the compiler missed though: it's hard to follow all the `goto`s. As you find out in [obfuscation.html](obfuscation.html) it's -134 after pre-processing! Yes I might be mad. But then again I might just be -the Devil. Who knows? What I do know is code that is meant to be reached is -reached! Yes I've played it many times. Some code I made dead seemed totally -useless but why not add to confusion? If that includes one that the compiler -misses that's even better! +134 after pre-processing! One of the alt versions I supplied is 131 before the +cpp and 149 after. I did not submit that for practical reasons but I kind of +wish I had, now that it won. Nonetheless 134 is already way too many. 149 is +much worse. + +Yes I might be mad. But then again I might just be the Devil. Who knows? What I +do know is code that is meant to be reached is reached! Yes I've played it many +times. Some code I made dead seemed totally useless but why not add to +confusion? If that includes one that the compiler misses that's even better! It is **NOT** a bug where in the inner switch there is a missing case. That is done because I do not want it to always trigger. That is the one that is in a @@ -3017,7 +3021,12 @@ In general I think it's extremely hard to follow the flow of this program due to the abuse of 116 `goto`s, more than the BASIC game. 134 when pre-processed. But let's be honest, or 134 for a small C program is too many but to be only six fewer than a larger BASIC program? That is hard to fathom. Not that 116 is not -too many for larger programs...or one goto, for that matter. +too many for larger programs...or one goto, for that matter. As noted elsewhere, +an alt version has 131/149 gotos, before/after the cpp. I did not make it the +main version when submitting because I did not want to make the judges weep and +curse any more than they already had to (besides, it can't be 4666 bytes with +the extra `goto`s) but now that it's in I have no qualms about providing it as +alt code: if I am going to ruin `goto`s I might as well do it properly. Some things are clear about the program from visual inspection: @@ -3257,7 +3266,7 @@ Except on the Oregon Trail. I was right too: the entire game is worse, far far worse. After this won I did a full sequence. This is from start to finish and I include it for your amusement -(see [gotos.txt](gotos.txt) for the line changes including calls to prog.c +(see [jumps.txt](jumps.txt) for the line changes including calls to prog.c functions). Or horror. There are a few times where the line is the same but that only shows how very often the line changes. It is a total of **985** (!) changes, counting function calls, and **776** (!) excluding diff --git a/2024/ferguson1/gotos.c.txt b/2024/ferguson1/gotos.c.txt new file mode 100644 index 000000000..3d2b13bc4 --- /dev/null +++ b/2024/ferguson1/gotos.c.txt @@ -0,0 +1,134 @@ + goto A; + goto f; + goto PP; + goto hell; + goto M; + goto hell; + goto M; + goto G; + goto hell; + goto M; + goto hell; + goto M; + goto S; + goto hell; + goto M; + goto OO; + goto L; + goto i; + goto kk; + goto HA; + goto at; + goto I; + goto r; + goto II; + goto F; + goto c; + goto zz; + goto qq; + goto C; + goto N; + goto dd; + goto jj; + goto oo; + goto ee; + goto x; + goto heaven; + goto XT; + goto ET; + goto v; + goto x; + goto v; + goto ZZ; + goto bb; + goto s; + goto X; + goto v; + goto T; + goto y; + goto E; + goto d; + goto P; + goto to; + goto y; + goto TA; + goto BB; + goto LL; + goto uu; + goto JJ; + goto B; + goto h; + goto l; + goto e; + goto hell; + goto M; + goto Y; + goto P; + goto K; + goto tt; + goto Z; + goto W; + goto ha; + goto D; + goto m; + goto Z; + goto H; + goto Z; + goto g; + goto Z; + goto Z; + goto Z; + goto Y; + goto MM; + goto hell; + goto M; + goto J; + goto Q; + goto k; + goto W; + goto hell; + goto M; + goto q; + goto TT; + goto P; + goto U; + goto hell; + goto M; + goto QQ; + goto KK; + goto z; + goto k; + goto k; + goto k; + goto hell; + goto M; + goto M; + goto yy; + goto Z; + goto rr; + goto hell; + goto M; + goto a; + goto Z; + goto Z; + goto Z; + goto go; + goto ii; + goto o; + goto V; + goto Z; + goto Y; + goto O; + goto W; + goto b; + goto n; + goto p; + goto x; + goto j; + goto n; + goto R; + goto t; + goto n; + goto u; + goto w; + goto _; diff --git a/2024/ferguson1/index.html b/2024/ferguson1/index.html index 24da10042..008d95bf5 100644 --- a/2024/ferguson1/index.html +++ b/2024/ferguson1/index.html @@ -2450,11 +2450,14 @@ might be one that the compiler does not trigger a dead code warning on. It really does not seem to be dead (it’s quite sneaky).

    I could be wrong on whether this is one the compiler missed though: it’s hard to follow all the gotos. As you find out in obfuscation.html it’s -134 after pre-processing! Yes I might be mad. But then again I might just be -the Devil. Who knows? What I do know is code that is meant to be reached is -reached! Yes I’ve played it many times. Some code I made dead seemed totally -useless but why not add to confusion? If that includes one that the compiler -misses that’s even better!

    +134 after pre-processing! One of the alt versions I supplied is 131 before the +cpp and 149 after. I did not submit that for practical reasons but I kind of +wish I had, now that it won. Nonetheless 134 is already way too many. 149 is +much worse.

    +

    Yes I might be mad. But then again I might just be the Devil. Who knows? What I +do know is code that is meant to be reached is reached! Yes I’ve played it many +times. Some code I made dead seemed totally useless but why not add to +confusion? If that includes one that the compiler misses that’s even better!

    It is NOT a bug where in the inner switch there is a missing case. That is done because I do not want it to always trigger. That is the one that is in a sense polymorphic. One of the events is actually immediate death, in particular @@ -2897,7 +2900,12 @@ I mentioned in obfuscation.html (and some briefly the abuse of 116 gotos, more than the BASIC game. 134 when pre-processed. But let’s be honest, or 134 for a small C program is too many but to be only six fewer than a larger BASIC program? That is hard to fathom. Not that 116 is not -too many for larger programs…or one goto, for that matter.

    +too many for larger programs…or one goto, for that matter. As noted elsewhere, +an alt version has 131/149 gotos, before/after the cpp. I did not make it the +main version when submitting because I did not want to make the judges weep and +curse any more than they already had to (besides, it can’t be 4666 bytes with +the extra gotos) but now that it’s in I have no qualms about providing it as +alt code: if I am going to ruin gotos I might as well do it properly.

    Some things are clear about the program from visual inspection: