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/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.
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.
#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 @@ -2449,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!
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
@@ -2896,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.
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:
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 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 (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.
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 +3123,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
+embrace it to do this. I went full out and I could have fit moregotos (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.gotos in: not +only is the iocccsize not 2503 but I could have removed some events if I really +wanted moregotos.Even flex/bison code, which as far as I am aware uses FAR fewer
@@ -3228,8 +3240,9 @@ the degree I have taken it in this program, it demonstrates why you should avoidgotos, is notorious forgotos and is quite hard to follow. It would be a nightmare to try and maintain without the .l/.y source files.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
+gotothat 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
@@ -3703,6 +3716,7 @@ helps you appreciate the careful design even more.prog.c - entry source codegotothat 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 ONEgotoled to a CVE!
goto
Here’s the horrifying and hilarious truth: I beat it out by 92 MORE, BEFORE the
cpp at 116 and after the cpp is through I beat it by 110 MORE (!!), AT
-134! Yes, you read that right. 134 gotos!
+134! Yes, you read that right. 134 gotos! I even went further in an alt
+version, where before the cpp it was 131 gotos and after the cpp 149 (!!)
+gotos. I didn’t do this in the main entry for practical reasons but I wish I
+had.
Even removing what I think are the only dead gotos, two of them, including one
that is in the w() macro that would be translated into more, I beat it by 90
more, at 114 before the cpp, and 99 more after the cpp, at 123!
@@ -510,16 +513,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..2663455cf 100644
--- a/2024/ferguson1/obfuscation.md
+++ b/2024/ferguson1/obfuscation.md
@@ -50,7 +50,10 @@ many. Unless I am very much mistaken, I have broken the record by a huge margin.
Here's the horrifying and hilarious truth: I beat it out by 92 MORE, **BEFORE** the
cpp at 116 and after the cpp is through I beat it by **110** MORE (!!), **AT
-134!** Yes, you read that right. 134 `goto`s!
+134!** Yes, you read that right. 134 `goto`s! I even went further in an alt
+version, where before the cpp it was 131 `goto`s and after the cpp 149 (!!)
+`goto`s. I didn't do this in the main entry for practical reasons but I wish I
+had.
Even removing what I think are the only dead `goto`s, two of them, including one
that is in the `w()` macro that would be translated into more, I beat it by 90
@@ -68,18 +71,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
diff --git a/2024/ferguson1/prog.goto.max.c b/2024/ferguson1/prog.goto.max.c
new file mode 100644
index 000000000..28edc5aa5
--- /dev/null
+++ b/2024/ferguson1/prog.goto.max.c
@@ -0,0 +1,85 @@
+#include
+#include
+#include
+#include
+#include
+long x(long y, long z){ return rand()%(z-y+1)+y; }
+unsigned m,D,Q,v,l,f,X,z,B,i,h,
+ r,u,d,e; long
+O,R,E,G,O,N, T,R,A,I,L,
+*o[]={ &O,&R,&E,&G,&O,&N} ,a,t[7],q,M, b=666,c,W;
+char *y,*p; FILE*K; size_t J;
+#define w(i) { V(i); V(4); goto hell; goto M; }
+long Z(long x){ return x * 1663; }
+#define S(x,z) while(scanf(&y[Z(x)],&z)!=1)while(getchar()!='\n');
+void V(long x){ printf("%s",&y[Z(x)]); }
+long k() { return E>0?x(0,99)>49:0; } int main() {
+switch(1)
+ { j:if(z)goto A; E*=5; B:
+ printf(&y[Z(12)],T); if(z) { goto f; } goto PP; default: srand(time(0));
+K=fopen(DATA,"r"); if(!K||getdelim(&y,&J,EOF,K)<0)
+ goto hell; goto M; OO: if(b<1) { if(a){ w(40) PP: goto G; } if(f) w(41) w(45) g:goto S; } w(M>2169?47:45)
+ hell:
+ return
+ 666; rr:;
+
+ goto CC; yy:
+{ if(b<1||M<0||M>2169){ goto _; F:V(51); R+=18; goto L; } goto i;
+
+P:for(X=1; X<--(unsigned){ 7 } ; ){ goto kk; BB:*o[X]+=(X==2?t[X]*5:t[X]); goto HA; TA:++X; goto at; ZZ:; }
+printf(&y[Z(11)],R,E,G,O,N,T,b,M); if(x(0,1))goto I; R:if(R<14)V(37); if(z) { z=0; l: { if (k()) { if (x(0,9) > 4) { V(52);
+
+R+=23; if(!x(0,9)){ goto r; L: goto II; } c:; } else{ goto F; r: goto c; qq: { V(53); goto zz; } II:; } } else { goto qq; } zz: E-=9; M-=45; } goto C; y:V(42); S(2,r) switch(r) { M:V(1); v:memset(&t,0,sizeof t); goto
+ N; D:{ if (k()) { goto dd; ii:V(f=79); b -= 80; T/=4; goto jj; ee:; } else { goto oo; dd:V(a=29); T+=70; goto ee; x:V(X+--(
+unsigned){ 6 } ); if(z){ S(3,
+
+t[X])if(t[X]<0||t[X]>
+
+ 666 ){ V(14); goto x; goto
+ heaven ; ET:L-=t[u]; goto XT; } L=T; for(u
+
+ =0; u < 6; ++u){ goto ET; XT:; }
+
+ if(L<0){ V(46); memset(&t,0,
+
+ sizeof t); goto v; } }
+
+ else{ S(3 ,*(o[X])) if(
+
+ *o[X]<0||*o[X] >
+ 666) { V(14);
+
+ goto x; } T=1666-O-R-E-G-0-N; if(T<0){ V(46); O=R=E=G=N=0; goto v; LL:*o[X]=0; uu:++X; goto ZZ; } } goto bb; } } goto s; case 3: goto X; case 1:z=1; M-=45; goto v;
+case 2:goto T; } goto y;
+O:{ V(e = 19); O -= 40; R+=40; } goto E; i:if(O<1){ goto d; } else { goto vv; mm:; } goto P; go: V(81); R+=9; N+=3; goto to;
+} else{ goto y; HA:T-=X[t]; goto TA; A:for(X=1; X < 6; ){ goto BB; kk:if (*o[X]<0) goto LL; goto uu; QQ:V(B=38); goto JJ; at:; } goto B;
+} T:l=1; if (E<9){ goto h; } else { goto l; h: V(16); goto C; DD: goto u; } C: l=0; f:z=0;
+X:if(R<1){ goto e; U: w(24) K:R-=R
+ >23?23:R>18? 18 : R > 13 ? 13 :
+ R; goto Y; TT:V(v=15); O=0; goto P; } else { goto K; } goto tt; Y:switch(q=x(0,23))
+{ case 1:V(95); R+=5; goto Z; case 18:V(26); goto Z; case 13:V(28); goto Z;
+case 2:O-=40; V(71); goto Z; case 3:V(a=76); b-=70; goto W; case 4:V(77); N-=7; M-=7; goto Z; case 5:case
+10:if(q<6) { goto ha; m: V(56); goto D; CC: goto OO; o:; } else
+{ goto m; oo:V(f=62); M-=50; b-=35; s:; } goto Z; a:goto H;
+case 9:case 19:V(30); goto Z; case 20:V(32); goto Z; case 21 :V(31); goto Z; case 6:goto g; case 16: case 22:V(49); goto Z; case 17:V(72); goto Z;
+case 7:V(83); M-=10; goto Z; case 8:V(86); R-=30; G-=20; O-=40; V
+ :switch(x(1,9)){ case 2:if(q>9){ switch(x(1,2)){ q:R+=40; goto Y; case 1:{ switch (x(2,5)) { case 2:V(a=54); goto
+ MM; b:w(48)
+case 3:goto J; N:goto Q; case 4:i=17; } } case 2: V(5); } goto k; u: if(M<1951||W){ goto
+W; } W=1;
+if(!d&&!x(0,4)){ V(75); d=1; R+= 50; }
+if(!x(0,3)){ w(x(0,4)?84:x(0,4)?33:34) e:if(O>39){ goto xx; vv:v=0; goto mm; d:{ if(!v)goto TT; goto P; } } goto U; } if (x(0,9) < 5) w:V(35); c=1; M-=101; ++E; k: M-=10; W: if(x(0,1)){ if (d) V(39); if(e)V(25); } while(i)heaven:{ w(i) } if (!B&&(f||
+a)){ if(d&&a) V(91); if(T<666){ goto QQ; KK:Q=a?1:Q; h=f?1:h; f=a=0; V(93); T-=666; } else{ goto KK; } JJ:; } b-=f?15
+
+ :h?5:0; b-=a?5:Q?15:0; M+=170; M+=O> 99 ? 30:- 99;
+
+b-=10; goto z; J: V(a=54); } goto k; MM
+
+ :goto k; default: if(q>10) { goto k; } if(q>7) { if(N<5) { w(99) goto M; G:goto yy; } V(13); N-=5; } goto Z; _:goto rr; S:if (E>1999){ w(27) I:goto a; } V(82); M-=9; N-=5; R-=20; goto Z;
+ } M-=17; goto Z; case 14: V(74); goto Z; case 15: V(x(0,1)?69:68);
+ goto Z; ha:V(78); if(k()){ goto go; to:; } else { goto ii; jj:; } goto o; case 11: goto V; case
+ 12:V(94); M-=5; b-=19; N -= 5; goto Z; tt: goto Y; case 0:V(20); Z:; } if(O>39&&!x(0,9)){goto O; xx: V(e=x(0,1)?18:19); O -= 40; goto q; } E: if(M<951) goto W; if (G < 36){ goto b; } if (x(0,9) > 2) goto n; V(96); if (x(0,1)) { goto p; Q: for (X=
+1; X < 6; ++X) { goto x; bb:; } goto j; } V(97); M-= 60; goto n; H:goto R; p: if (x(0,9)<3) goto t; V(21); M -=99;
+goto n; t: V(22); M -= 85; n:if(m){ goto DD; } m=1; if (x(0,9) > 5) goto w; V(23); z:; } if (A++<21) goto yy; goto _;
+}
+}
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
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:
Winners were announced during a live the Our Favorite Universe YouTube Channel that started on 2025-08-02 18:00:00.000000 UTC
Near the end of the 2 hour XXX-add-show-URL-here-XXX YouTube show, the source code of the IOCCC28 winning entries was published on IOCCC GitHub winner repo and on the Official IOCCC website.
Winners were announced during a live show that started on 2025-08-02 18:00:00.000000 UTC +on the Our Favorite Universe +YouTube Channel.
At about 03h:42m:03s mark in the 04h:30m:35s YouTube +show, the source code of the +IOCCC28 winning entries was published on IOCCC GitHub winner +repo and on the Official IOCCC +website.
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.
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.
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).
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 theThe 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.
If you use the 2024/mills/try.sh script, you will first be given an opportunity to view the 2024/mills/prog.c source code. Then you will be given 10 choices to play.
@@ -626,7 +633,7 @@ reading/navigating the twisty mazes of this source code! :-)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!Depending on the address of a variable, as not all platforms support -ASLR, -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. +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.
When working with modern C compilers, it’s crucial to explicitly
declare variable and function types. Don’t assume they’ll
automatically default to an int.
If your submission relies on mathematical algorithms, be sure that the 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!
Using a lot of goto statements to make your code harder to understand might not help it pass the final rounds of judging.
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: