diff --git a/2019/diels-grabsch1/.gitignore b/2019/diels-grabsch1/.gitignore index ea1749132..e86bb0e4d 100644 --- a/2019/diels-grabsch1/.gitignore +++ b/2019/diels-grabsch1/.gitignore @@ -1 +1,5 @@ prog +dg1.Z +ref.Z +guidelines.txt.Z +guidelines2.txt diff --git a/2019/diels-grabsch1/README.md b/2019/diels-grabsch1/README.md index c792d13b7..44cabc3f0 100644 --- a/2019/diels-grabsch1/README.md +++ b/2019/diels-grabsch1/README.md @@ -1,7 +1,7 @@ # Best small program - Volker Diels-Grabsch - +Volker Diels-Grabsch + ## To build: @@ -9,6 +9,12 @@ make ``` +[Cody Boone Ferguson](/winners.html#Cody_Boone_Ferguson) made the author's +statement that the entry compiles cleanly true by fixing `warning: a function +declaration without a prototype is deprecated in all versions of C ` (in +main()). Not strictly necessary but if he's making fixes he might as well. Thank +you Cody! + ## To run: ```sh @@ -22,6 +28,7 @@ dd bs=1024 count=2048 < /dev/zero | compress > ref.Z dd bs=1024 count=2048 < /dev/zero | ./prog > dg1.Z cmp ref.Z dg1.Z +cd ../mills ; make ; cd ../diels-grabsch1 compress < ../mills/Shakespeare.txt > ref.Z ./prog < ../mills/Shakespeare.txt > dg1.Z cmp ref.Z dg1.Z # Oops, the files differ @@ -30,40 +37,45 @@ zcat < dg1.Z | cmp - ../mills/Shakespeare.txt # Decompresses correctly. What is ## Judges' comments: -Finally, IOCCC now has its own text compression program, and it is short -enough to qualify for the Best Short Program award! That said, can you -compress it down to a one-liner, still producing files in the UNIX compress format, -albeit sacrificing the compression ratio? +Finally, IOCCC now has its own text compression program, and it is short enough +to qualify for the Best Short Program award! That said, can you compress it down +to a one-liner, still producing files in the UNIX compress format, albeit +sacrificing the compression ratio? Can you explain why the zero file compresses identically by the entry and the -standard compress tool, but the text file compresses differently? The judges know. :) +standard compress tool, but the text file compresses differently? The judges +know. :) ## Author's comments: -### A tiny "compress" tool +### A tiny "compress" tool: -`Usage:` +#### Usage: + +```sh +./prog < input.txt > input.txt.Z +``` + +#### Example: ```sh ./prog < guidelines.txt > guidelines.txt.Z ``` -`Check for correctness:` +#### Check for correctness: ```sh zcat guidelines.txt.Z > guidelines2.txt diff -s guidelines.txt guidelines2.txt ``` -`Of course you can` -`also use 2015/mills2 instead of zcat to verify the output` -`file. The achieved compression ratio roughly matches that` -`of the classic Unix compress tool. And the source code is` -`very compressed, too: It has exactly the same size as the` -`paragraph you are reading right now. And exactly the same` -`shape. Nevertheless, it is portable C99 code that runs on` -`32-bit and 64-bit platforms. It compiles without warnings` -`on both GCC and Clang even with -Wextra and -Weverything.` +Of course you can also use [2015/mills2](/2015/mills2/mills2.c) instead of +`zcat` to verify the output file. The achieved compression ratio roughly matches +that of the classic Unix compress tool. And the source code is very +compressed, too: It has exactly the same size as the paragraph you are reading +right now. And exactly the same shape. Nevertheless, it is portable C99 code +that runs on 32-bit and 64-bit platforms. It compiles without warnings on both +GCC and Clang even with `-Wextra and -Weverything`. ## Copyright and CC BY-SA 4.0 License: diff --git a/2019/diels-grabsch1/guidelines.txt b/2019/diels-grabsch1/guidelines.txt new file mode 100644 index 000000000..52051e906 --- /dev/null +++ b/2019/diels-grabsch1/guidelines.txt @@ -0,0 +1,961 @@ +| 26th International Obfuscated C Code Contest Official Guidelines + +| Copyright (C) 2006-2018 Leonid A. Broukhis, Simon Cooper, Landon Curt Noll. + +All Rights Reserved. Permission for personal, education or non-profit use is +granted provided this this copyright and notice are included in its entirety +and remains unaltered. All other uses must receive prior permission in +writing from the contest judges. + +| This guidelines file is version 2018-12-25-v26. + +| Most of the changes from the previous IOCCC guideline set +| have been marked with a "|" on the left hand side of the line. + + + +ABOUT THIS FILE: + + This file contains guidelines intended to help people who wish to + submit entries to the International Obfuscated C Code Contest (IOCCC). + + This is not the IOCCC rules, though it does contain comments about + them. The guidelines should be viewed as hints and suggestions. + Entries that violate the guidelines but remain within the rules are + allowed. Even so, you are safer if you remain within the guidelines. + + You should read the current IOCCC rules, prior to submitting entries. + The rules are typically sent out with these guidelines. + + We recommend that you follow the twitter handle: + + @IOCCC + + to learn about IOCCC news, important IOCCC related alerts, IOCCC + reminders, and changes to the rules and these guidelines. + + You do not have to be a twitter user to follow @IOCCC. Non-twitter + users should access: + + https://twitter.com/ioccc + + Non-twitter users should force their browsers to reload the above URL + to be sure they are seeing the most recent tweets. + + While we try to post use news at: + + http://www.ioccc.org/index.html#news + + such postings may be delayed or obscured by slow to respond mirrors. + + +| WHAT'S NEW IN 2018/2019: + + This IOCCC runs from: + +| 2018-Dec-26 16:06:69 == 2018-Dec-26 16:07:09 UTC + to: +| 2019-Mar-15 00:86:07 == 2019-Mar-15 01:26:07 UTC + +| The reason for the time of day due to Erdős, an amazing mathematician +! that at least one of the IOCCC judges had the pleasure of working with. + + Until the start of this IOCCC, these rules, guidelines and iocccsize.c tool + should be considered provisional BETA versions and may be adjusted + at any time. + +| Even though the contest will start in 2018, because the contest will close +| in 2019, URLs, subject lines, and contest related email addresses use 2019. + + The IOCCC submission URL: + + https://submit.ioccc.org/ + +| The submit URL should be active on or slightly before 2019-Jan-15 15:15:15 UTC. +| Please wait to submit your entries until after that time. + + The official rules, guidelines and iocccsize.c tool will be available + on the official IOCCC web site on or slightly before start of this IOCCC. + Please check the IOCCC web site "How to enter" link: + + http://www.ioccc.org/index.html#enter + + on or after the start of this IOCCC to be sure you are using the correct + versions of these items before using the IOCCC entry submission URL. + + +HINTS AND SUGGESTIONS: + + You are encouraged to examine the winners of previous contests. See + FOR MORE INFORMATION for details on how to get previous winners. + + Keep in mind that rules change from year to year, so some winning entries + may not be valid entries this year. What was unique and novel one year + might be 'old' the next year. + + An entry is usually examined in a number of ways. We typically apply + a number of tests to an entry: + + * look at the original source + * convert ANSI tri-graphs to ASCII + * C pre-process the source ignoring '#include' lines + * C pre-process the source ignoring '#define' and '#include' lines + * run it through a C beautifier + * examine the algorithm + * compile it (with flags to enable all warnings) + * execute it + + You should consider how your entry looks in each of the above tests. + You should ask yourself if your entry remains obscure after it has been + 'cleaned up' by the C pre-processor and a C beautifier. + + Your entry need not pass all of the above tests. In certain + cases, a test is not important. Entries that compete for the + 'strangest/most creative source layout' need not do as well as + others in terms of their algorithm. On the other hand, given + two such entries, we are more inclined to pick the entry that + does something interesting when you run it. + + We try to avoid limiting creativity in our rules. As such, we leave + the contest open for creative rule interpretation. As in real life + programming, interpreting a requirements document or a customer request + is important. For this reason, we often award 'worst abuse of the + rules' to an entry that illustrates this point in an ironic way. + + We do realize that there are holes in the rules, and invite entries + to attempt to exploit them. We will award 'worst abuse of the rules' + and then plug the hole next year. Even so, we will attempt to use + the smallest plug needed, if not smaller. :-) + +| There are 2^5+1 reasons why these guidelines seem obfuscated. + + Check out your program and be sure that it works. We sometimes make + the effort to debug an entry that has a slight problem, particularly + in or near the final round. On the other hand, we have seen some + of the best entries fall down because they didn't work. + + We tend to look down on a prime number printer that claims that + 16 is a prime number. If you do have a bug, you are better off + documenting it. Noting "this entry sometimes prints the 4th power + of a prime by mistake" would save the above entry. And sometimes, + a strange bug/feature can even help the entry! Of course, a correctly + working entry is best. Clever people will note that 16 might be prime + under certain conditions. Wise people, when submitting something clever + will fully explain such cleverness in their entry's remarks file. + + People who are considering to just use some complex mathematical + function or state machine to spell out something such as "hello, + world!" really really, and we do mean really, do need to be more creative. + + Ultra-obfuscated programs are, in some cases, easier to + deobfuscate than subtly-obfuscated programs. Consider using + misleading or subtle tricks layered on top of or under an + appropriate level of obfuscation. A clean looking program with + misleading comments and variable names might be a good start. + + When programs use VTxxx/ANSI sequences, they should NOT limited to a + specific terminal brand. Those programs that work in a standard xterm + are considered more portable. + + Rule 2 (the size rule) has been changed. In particular rule 2 refers to + the use of an IOCCC size tool. The source for this tool is found at: + +| http://www.ioccc.org/2019/iocccsize.c + + To further clarify rule 2, we subdivided it into two parts, 2a and 2b. + Your entry must satisfy both the maximum size rule 2a AND your entry + must satisfy the IOCCC size tool rule 2b. + + The IOCCC size tool should be compiled as: + + cc -pedantic -Wall -Wextra -std=c11 iocccsize.c -o iocccsize + + This tool imposes a 2nd limit on C code size (rule 2b). To check your + code against the 2nd limit of rule 2, use the -i command line option. + For example: + + ./iocccsize -i < prog.c + + The IOCCC size tool, when using the -i option, may be summarized as: + + The size tool counts most C reserved words (keyword, secondary, + and selected preprocessor keywords) as 1. The size tool counts all + other octets as 1 excluding ASCII whitespace, and excluding any + ';', '{' or '}' followed by ASCII whitespace, and excluding any + ';', '{' or '}' octet immediately before the end of file. + + ASCII whitespace includes ASCII tab, ASCII space, ASCII newline, + ASCII formfeed, and ASCII carriage return. + + In cases where the above summary and the algorithm implemented by + the IOCCC size tool source code conflict, the algorithm implemented + by the IOCCC size tool source code is preferred by the judges. + + There are at least 2 other reasons for selecting 2053 as the 2nd limit + besides the fact that 2053 is the next prime > 2048. These reasons + may be searched for and discovered if you are "Curios!" about 2053. :-) + Moreover, 2053 was the number of the kernel disk pack of one of the + judge's BESM-6. + + Take note that this secondary limit imposed by the IOCCC size tool + obviates some of the need to #define C reserved words in an effort + to get around the size limits of rule 2. + + Yes Virginia, that is a hint! + + +OUR LIKES AND DISLIKES: + + Doing masses of #defines to obscure the source has become 'old'. We + tend to 'see thru' masses of #defines due to our pre-processor tests + that we apply. Simply abusing #defines or -Dfoo=bar won't go as far + as a program that is more well rounded in confusion. + + Many C compilers dislike the following code, and so do we: + + #define d define + #d foo /* <-- don't expect this to turn into #define foo */ + + When declaring local or global variables, you should declare the type: + + int this_is_fine; + this_is_not; /* <-- Try to avoid implicit type declarations */ + + We suggest that you compile your entry with a commonly available + c11 (formerly C1X) C compiler (ISO/IEC 9899:2011). + + Do not assume that optional c11 features are supported. If you + must use an optional c11 feature, use feature test macros so + that implementations without such optional c11 features will see + an entry that is both functional and interesting. + + We like entries that have workarounds that allow someone with + an older c99 (ISO/IEC 9899:1999) compiler to be able to compile + and enjoy your entry. + + We really like "lint free" code. However lint is a toll of the past. + So try to ensure that your entry compiles warning free. If possible, + to compile compile your code using: + + -Wall -Wextra -pedantic + + For compilers, such as clang, that have the -Weverything option, try + to make your code compile warning free using: + + -Wall -Wextra -Weverything -pedantic + + If you must turn off various warnings on the compile line such as: + + ... -Wno-empty-body -Wno-return-type ... + + be sure to clearly state so in your remarks AS WELL AS in + your "how to build" / Makefile. + + All other things being equal, a program that must turn off fewer + warnings will be considered better, for certain values of better. + + Unless you clearly state otherwise in your remarks AS WELL AS in + your "how to build" / Makefile we will compile using: + + -O3 -std=c11 + + Anyone care to submit an entry that makes gratuitous use of all + of the c11 reserved words in their intended C language contexts? + NOTE: As with the use of the word Belgium, the use of certain gratuitous + c11 reserved words may be completely banned in all parts of the Galaxy, + except in one small part (ISO/IEC 9899:2011) where they might not truly + understand the implications of such words. + + http://hitchhikers.wikia.com/wiki/Belgium + http://www.bezem.de/pdf/ReservedWordsInC.pdf + + DO NOT assume that we will use gcc to compile your program. + We will first try to compile your program using Clang. + + It is much better to not use any obscure compiler flags if + you can help it. We want to discourage the use of obscure compiler + flags that would make the program less portable. + + One side effect of the above is that you cannot assume the use + of nested functions such as: + + main() { +| void please_do_not_do_this() { +| printf("The machine that goes BING!\n"); + } +| please_do_not_do_this(); + } + + This is because such nested functions often requires one to compile with + a flag such as -fnested-functions that is not found on some compilers. + + On 2012 July 20, the judges rescinded the encouragement of + nested functions. Such constructions, while interesting and sometimes + amusing, will have to wait until they required by a C standard that are + actually implemented in commonly used C compilers. Sorry! + +| We prefer programs that do not require a fish license, crayons not +| withstanding. + + If your entry uses functions that have a variable number of + arguments, be careful. Systems implement va_list as a wide variety + of ways. Because of this, a number of operations using va_list are + not portable and must not be used: + + * assigning a non-va_list variable to/from a va_list variable + * casting a non-va_list variable into/from a va_list variable + * passing a va_list variable to a function expecting a non-va_list arg + * passing a non-va_list variable to a function expecting a va_list arg + * performing arithmetic on va_list variables + * using va_list as a structure or union + + In particular, do not treat va_list variables as if they were a char **'s. + + Avoid using . Use instead. + + On 28 January 2007, the Judges rescinded the requirement that the + '#" in a C preprocessor directive must be the 1st non-whitespace octet. + + The exit() function returns void. Some broken systems have exit() + return int, your entry should assume that exit() returns a void. + +| This guideline has a change mark at the very beginning is this line. + + Small programs are best when they are short, obscure and concise. + While such programs are not as complex as other winners, they do + serve a useful purpose. They are often the only program that people + attempt to completely understand. For this reason, we look for + programs that are compact, and are instructional. + +| While those who are used to temperatures found on dwarf planet, +| (yes Virginia, dwarf planets are planets) such as Pluto might be able to +| explain to the Walrus why our seas are boiling hot, the question of +| whether pigs have wings is likely to remain a debatable point to most. + + One line programs should be short one line programs: say around 80 to 120 + octets long. Going well beyond 140 octets is a bit too long to be called + a one-liner in our vague opinion. + + We tend to dislike programs that: + + * are very hardware specific + * are very OS version specific + (index/strchr differences are OK, but socket/streams specific + code is likely not to be) + * dump core or have compiler warnings + (it is OK only if you warn us in the 'remark' header item) + * won't compile or run under a POSIX P1003.1/P1003.2 like systems + * depend on a utility or application not normally found on most + most POSIX P1003.1/P1003.2 like systems + * abuse the build file to get around the size limit + * obfuscate by excessive use of ANSI tri-graphs + * are longer than they need to be + * are "blob-ier" than they need to be + * are rather similar to previous winners :-( + * are too similar to previous losers :-) + + Unless you are cramped for space, or unless you are entering the + 'best one liner' category, we suggest that you format your program + in a more creative way than simply forming excessively long lines. + + At least one judge prefers to maintain the use of the leap-second + as part of the world's time standard. If your code prints time + with seconds, we prefer that your code be capable of printing the + time of day during a leap-second where the value in seconds + after the minute mark is 60. + + The "how to build" make process should not be used to try and get + around the size limit. It is one thing to make use of a several -D's + on the compile like to help out, but it is quite another to use many + bytes of -D's in order to try and squeeze the source under the size limit. + + The judges, as a group, have a history giving wide degree of latitude + to reasonable entries. And recently they have had as much longitudinal + variation as it is possible to have on Earth. :-) + + You should try to restrict commands used on the build file to + POSIX-like or common Un*x-like commands. You can also compile + and use your own programs. If you do, try to build and execute + from the current directory. This restriction is not a hard and + absolute one. The intent is to ensure that the building if your + program is reasonably portable. + + We prefer programs that are portable across a wide variety of Un*x-like +| operating systems (i.e., Linux, GNU Hurd, BSD, Un*x, etc.). + + You are in a maze of twisty guidelines, all different. + + There are at least zero judges who think that Fideism has little + or nothing to do with the IOCCC judging process. + + Don't forget that the building of your program should be done + ***without human intervention***. So don't do things such as: + + prog: prog.c + #echo this next line requires data from standard input + cat > prog.c + ${CC} prog.c -o prog + + However, you can do something cute such as making your program + do something dumb (or cute) when it is built 'automatically'. And + when it is run with a human involved, do something more clever. + For example, one could use the build instructions: + + prog: prog.c + ${CC} prog.c -DNON_HUMAN_COMPILE -o prog + @echo "See remarks section about alternate ways to compile" + + and then include special notes in the program "remarks" for + alternate / human intervention based building. + + We want to get away from source that is simply a compact blob of + octets. Really try to be more creative than blob coding. *HINT!* + + Please do not use things like gzip to get around the size limit. +| Please try to be much more creative. + + We really dislike entries that make blatant use of including + large data files to get around the source code size limit. + + We do not recommend submitting systemd source code to the IOCCC, + if nothing else because that code is likely to exceed the source code + size limit. This isn't to say that another highly compact and obfuscated + replacement of init would not be an interesting submission. + + Did we remember to indicate that programs that blatantly use + some complex state machine to do something simple are boring? + We think we did. :-) + + All generalizations are false, including this one. -- Mark Twain + + Given two versions of the same program, one that is a compact blob + of code, and the other that is formatted more like a typical C + program, we tend to favor the second version. Of course, a third + version of the same program that is formatted in an interesting + and/or obfuscated way, would definitely win over the first two! + Remember, you can submit more than one entry. See the rules for details. + + We suggest that you avoid trying for the 'smallest self-replicating' + source. The smallest, a zero byte entry, won in 1994. + + Programs that claim to be the smallest C source that does something, really + better be the smallest such program or they risk being rejected because + they do not work as documented. + + Please note that the C source below, besides lacking in obfuscation, + is NOT the smallest C source file that when compiled and run, dumps core: + + main; + + We do not like writable strings. That is, we don't want stuff like: + + char *T = "So many primes, so little time!"; + ... + T[14] = ';'; + + Please don't make use of this feature, even if your system allows it. + However, initialized char arrays are OK to write over. This is OK: + + char b[] = "Is this OK"; + b[9] = 'K'; + +| There are more than one typos in this sentence. + + X client entries should be as portable as possible. Entries that + adapt to a wide collection of environments will be favored. For + example, don't depend on a particular type or size of display. + Don't assume the use of a particular browser. Instead assume a + generic browser that forms to a widely used W3C standard. + Don't assume a particular sound sub-system or video driver is installed + in the OS. Instead, make use of a well known and widely available open + source program (one that actually works) to display audio/visual data. + + X client entries should avoid using X related libraries and + software that is not in wide spread use. + + This is the only guideline that contains the word fizzbin. +| However, do you know how to play fizzbin? + + We don't like entries that use proprietary toolkits such as the M*tif, + Xv*ew, or OpenL*ok toolkits, since not everyone has them. Use of an + open source toolkit that is widely and freely available instead. + + The previous guideline in this spot has been replaced by this guideline. + + X client entries should not to depend on particular items on + .Xdefaults. If you must do so, be sure to note the required lines + in the program "remarks". They should also not depend on any + particular window manager. + + Try to avoid entries that play silent sound segments or play the + Happy Birthday song; music that some people believe is copyrighted + (even if such copyrights appear to be bogus and/or blatant abuses of + the copyright system). + + While we recognize that UN*X is not a universal operating system, the + contest does have a bias towards such systems. In an effort to expand + the scope of the contest, we phrase our bias in terms of POSIX P1003.1 + and P1003.2 standards. This will allow certain non-UN*X OS users to + submit entries. On the other hand, this is a guideline and not a rule. + We will not reject an entry based on some POSIX technicality. + + When dealing with OS and application environments, we suggest that you + be reasonable with a nod towards vanilla UN*X-like systems. POSIX will + evolve but not as much as the contest. + + You very well might not be completely prohibited from failing to not + partly misunderstand this particular guideline, but of course we could +| not possibly comment. Nevertheless, you are neither prohibited, nor +| required to determine that this or the previous sentence is either false +| and/or misleading. Therefore, it might be wise to not fail to consider +| to do so, accordingly. + +| Any complaints about the above guideline could be addressed to the +| Speaker of the House of Commons, or to the speaker of your national +| pariliment should you have one. + + We like programs that: + + * are as concise and small as they need to be + * do something at least quasi-interesting + * are portable + * are unique or novel in their obfuscation style + * MAKE USE OF A NUMBER OF DIFFERENT TYPES OF OBFUSCATION <== HINT!! + * make us laugh and/or throw up :-) (humor really helps!) + * make us want to eat good chocolate. + + Some types of programs can't excel (anti-tm) in some areas. Your + program doesn't have to excel in all areas, but doing well in several + areas really does help. + + You are better off explaining what your entry does in the program + "remarks" section rather than leaving it obscure for the judges + as we might miss something and/or be too tired to notice. + +| Please avoid this specific individual guideline, if possible. + + We freely admit that interesting, creative or humorous comments in + the program "remarks" help your chances of winning. If you had to + read so many twisted entries, you too would enjoy a good laugh or two. + We think the readers of the contest winners do as well. We do read + the program "remarks" during the judging process, so it is worth your + while to write remarkable program "remarks". + + We dislike C code with trailing control-M's (\r or \015) that results + in compilation failures. Some non-Un*x/non-Linux tools such as + MS Visual C and MS Visual C++ leave trailing control-M's on lines. + Users of such tools should strip off such control-M's before submitting + their entries. In some cases tools have a "Save As" option that will + prevent such trailing control-M's being added. + + One should restrict libcurses to portable features found on BSD + or Linux curses. + + Rule 13 states any C source that fails to compile because of unescaped + octets with the high bit set (octet value >= 128) will be rejected. + Instead of unescaped octets, you should use \octal or \hex escapes: + + /* 123456789 123456789 123456789 123456 */ + char *foo = "This string is 36 octets in length \263"; + /* This octet requires 4 octets of source ^^^^ */ + if (strlen(foo) == 36) printf("foo is 36 octets plus a final NUL\n"); + else printf("This code should not print this message\n"); + + It is a very good idea to, in your remarks file, tell us why you + think your entry is obfuscated. This is particularly true if + your entry is has some very subtle obfuscations that we might + otherwise overlook. <<-- Hint! + + Anyone can format their code into a dense blob. A really clever + author will try format their entry using a "normal" formatting style + such that at first glance (if you squint and don't look at the details) + the code might pass for non-obfuscated C. Deceptive comments, + and mis-leading formatting, in some cases, may be a plus. On the + other hand, a misleading code style requires more source bytes. + + If you do elect to use misleading formatting and comments, we + suggest you remark on this point in your remarks where you talk + about why you think your entry is obfuscated. On the other hand, + if you are pushing up against the size limits, you may be forced + into creating a dense blob. Such are the trade offs that obfuscators face! + + We prefer code that can run on either a 64-bit or 32-bit processor. + However, it is unwise to assume it will run on an i386 or x86 architecture. + + We believe that Mark Twain's remark: + + Get your facts first, then you can distort them as you please. + + is a good guideline for those writing code for the IOCCC. + + The IOCCC size tool source, iocccsize.c, is not an original work. + Submitting an entry based on our iocccsize.c violates rule 8, + even if you write that code! + + Rule 8 does not prohibit you from writing your own obfuscated IOCCC size tool. + However if you do, you might wish to make your tool do something more + interesting than simply implementing the IOCCC size tool algorithm. + + While programs that only run in a specific word size are OK. If you have + to pick, choose a 64-bit word size. + + If we are feeling ornery we might choose to compile your program + for running on an Arduino or a PDP-11. Heck, should we ever find + an emulator of 60-bit CDC Cyber CPU running a POSIX-like OS, we + might just try your entry on that emulator as well :-) + + If your entry MUST run only in 32-bit mode on an Intel processor, add the + following compiler flag: + + -arch i386 + + to your "how to build" make compile line. For example: + + prog: prog.c + ${CC} prog.c -arch i386 -o prog + + Be even more creative! + + If there are limitations in your entry, you are highly encouraged + to note such limitations in your remarks file. For example if your + entry factors values up to a certain size, you might want to state: + + This entry factors values up 2305567963945518424753102147331756070. + Attempting to factor larger values will produce unpredictable results. + + The judges might try to factor the value -5, so you want to might state: + + This entry factors positive values up 2305567963945518424753102147331756070. + Attempting to factor large values will produce unpredictable results. + + However the judges might try to also factor 0, so you want to might state: + + This entry factors values between 1 and 2305567963945518424753102147331756070. + Attempting to factor values outside that range will produce unpredictable results. + + Moreover the try to also factor 3.5 or 0x7, or Fred, so you want to might state: + + This entry factors integers between 1 and 2305567963945518424753102147331756070. + Attempting to factor anything else will produce unpredictable results. + + You entry might be better off catching the attempt to factor bogus values + and doing something interesting. So you might want to code accordingly and state: + + This entry factors integers between 1 and 2305567963945518424753102147331756070. + Attempting to factor anything else will cause the program to insult your + pet fish Eric. + + The judges might not have a pet fish named Eric, so might want to state: + + This entry factors integers between 1 and 2305567963945518424753102147331756070. + Attempting to factor anything else will cause the program to insult your + pet fish Eric, or in the case that you lack such a pet, will insult the + pet that you do not have. + + When all other things are equal, an entry with fewer limitation will be judged + better than an entry with lots of limitations. So you might want to code accordingly + and state: + + This entry attempts to a factor value of any size provided that the program + is given enough time and memory. If the value is not a proper integer, the + program will insult a fish named Eric, even if such a fish does not exist. + + +ABUSING THE RULES: + + Legal abuse of the rules is somewhat encouraged. Legal rule abuse may + involve, but is not limited to, doing things that are technically + allowed by the rules and yet do not fit the spirit of what we intended + to be submitted. + + Legal rule abuse is encouraged to help promote creativity. Rule abuse + entries, regardless of if they receive an award, result in changes to + the next year's rules and guidelines. + + Legal abuse of the rules is NOT an invitation to violate the rules. + An entry that violates the rules in the opinion of the judges, WILL be + disqualified. RULE ABUSE CARRIES A CERTAIN LEVEL OF RISK! If you + have an entry that might otherwise be interesting, you might want to + submit two versions; one that does not abuse the rules and one that + does. + + If you intend to abuse the rules, indicate so in the program + "remarks". You must try to justify why you consider your rule abuse + to be allowed under the rules. That is, you must plead your case as + to why your entry is valid. Humor and/or creativity help plead a + case. + + Abusing the web submission procedure tends to annoy us more + than amuse us. Spend your creative energy on content of your + entry rather than on the submission process itself. + + We are often asked why the contest rules and guidelines seem too + strange or contain mistakes, flaws or grammatical errors. One reason + is that we sometimes make genuine mistakes. But in many cases such + problems, flaws or areas of confusion are deliberate. Changes to + rules and guidelines in response to rule abuses, are done in a minimal + fashion. Often we will deliberately leave behind holes (or introduce + new ones) so that future rule abuse may continue. A cleaver author + should be able to read them and "drive a truck through the holes" in + the rules and guidelines. + + At the risk of stating the obvious, this contest is a parody of the + software development process. The rules and guidelines are only a + small part of the overall contest. Even so, one may think the contest + rules and guideline process as a parody of the sometimes tragic + mismatch between what a customer (or marketing) wants and what + engineering delivers. Real programmers must face obfuscated + and sometimes conflicting specifications and requirements from marketing, + sales, product management an even from customers themselves on a + all too regular basis. This is one of the reasons why the rules and + guidelines are written in obfuscated form. + + +JUDGING PROCESS: + + Entries are judged by Leonid A. Broukhis, Simon Cooper, Landon Curt Noll. + + Each entry submitted is given a random id number and subdirectory. The + entry files including, but not limited to prog.c, Makefile (that we + form from around your "how to build" information), as well as any + data files that you submit are all placed under their own directory. + stored and judged from this directory. + + Any information about the authors is not read by the judges until + the judging process is complete, and then only from entries that have + won an award. Because we do not read this information for entries that + do not win, we do not know who did not win. + + The above process helps keep us biased for/against any one particular + individual. Therefore you MUST refrain from putting any information + that reveals your identity in your entry. + + Now some people point out that coding style might reveal the information + about the others. However we consider this to be simply circumstantial + and outside the scope of the above paragraph. + + Some people, in the past, have attempted to obfuscate their identity by + including comments of famous Internet personalities such as Peter Honeyman + (http://www.citi.umich.edu/u/honey/). The judges are on to this + trick and therefore consider any obfuscated source or data file + claiming to be from Honeyman to not be form Honeyman. This of course + creates an interesting paradox known as the "obfuscated Peter Honeyman + paradox". Should Peter Honeyman actually submit an obfuscated entry, + he alone is excluded from the above, as we will likely believe + it just another attempt at confusion. This guideline is known + as the "Peter Honeyman is exempt" guideline. + + BTW: None of the entries claiming to be from Peter Honeyman have ever + won an award. So it is theoretically possible that Peter Honeyman + did submit an entry in the past. In the past, Peter had denied + submitting anything to the IOCCC. Perhaps those entries were + submitted by one of his students? + +| Hopefully we are very CLEAR on this point! The rules now strongly state: +| PLEASE DO NOT put a name of an author, in an obvious way, into your + source code, remarks, data files, etc. The above "Peter Honeyman is + exempt" not withstanding. + + We seemed to have digressed again ... :-) Returning to the judging process: + + We prefer to be kept in the dark as much as you are until the final + awards are given. We enjoy the surprise of finding out in the end, + who won and where they were from. + + We attempt to keep all entries anonymous, unless they win an award. + Because the main 'prize' of winning is being announced, we make all + attempts to send non-winners into oblivion. We remove all non-winning + files, and shred all related paper. By tradition, we do not even + reveal the number of entries that we received. + + During the judging process. a process that spans multiple sessions + over a few weeks, post general updates from our @IOCCC twitter account. + + Once we have selected the winners, for each category we will tweet: + + category name + name(s) of the authors (or anonymous if requested) + twitter handle(s) (if provided and if anonymity was not requested) + country code(s) of the author(s) + + After the initial announcement, we attempt to send email to the + authors of the winning entries. One reason we do this is to give + the authors a chance to comment on the way we have presented their + entry. They are given the chance to correct mistakes and typos. We + often accept their suggestions/comments about our remarks as well. + This is done prior to posting the winners to the wide world. + + Judging consists of a number of elimination rounds. During a round, + the collection of entries are divided into two roughly equal piles; + the pile that advances on to the next round, and the pile that does + not. We also re-examine the entries that were eliminated in the + previous round. Thus, an entry gets at least two readings. + + A reading consists of a number of actions: + + * reading the "how to build" information and forming a Makefile + * reading prog.c, the C source + * reviewing the "remarks" information + * briefly looking any any supplied data files + * passing the source thru the C pre-processor + skipping over any #include files + * performing a number of C beautify/cleanup edits on the source + * passing the beautified source thru the C pre-processor + skipping over any #include files + * compiling/building the source + * running the program + * Doing other things that only IOCCC judges know about :-) + + In later rounds, other actions are performed including performing + miscellaneous tests on the source and binary. + +! This is the guideline that goes, BING! + + Until we reduce the stack of entries down to about 25 entries, entries + are judged on an individual basis. An entry is set aside because it + does not, in our opinion, meet the standard established by the round. + When the number of entries thins to about 25 entries, we begin to form + award categories. Entries begin to compete with each other for awards. + An entry will often compete in several categories. + + The actual award category list will vary depending on the types of entries + we receive. A typical category list might be: + + * best small one line program (see above about one line programs) + * best small program + * strangest/most creative source layout + * most useful obfuscated program + * best game that is obfuscated + * most creatively obfuscated program + * most deceptive C code (code with deceptive comments and source code) + * best X client (see OUR LIKES AND DISLIKES) + * best abuse of ISO C or ANSI C standard (see above about compilers) + * best abuse of the C preprocessor + * worst abuse of the rules + * (anything else so strange that it deserves an award) + + We do not limit ourselves to this list. For example, a few entries are so + good/bad that they are declared winners at the start of the final round. + We will invent awards categories for them, if necessary. + + In the final round process, we perform the difficult tasks of + reducing the remaining entries (typically about 25) down to to about + half that number: declaring those remaining to be winners. + + Often we are confident that the entries that make it into + the final round are definitely better than the ones that do not + make it. The selection of the winners out of the final round, is + less clear cut. + + Sometimes a final round entry is good enough to win, but is beat out + by a similar, but slightly better entry. For this reason, it is + sometimes worthwhile to re-enter an improved version of an entry + that failed to win in a previous year. This assumes, of course, + that the entry is worth improving in the first place! + + More than one IOCCC judge has been known to bribe another IOCCC judge + into voting for a winning entry by offering a bit high quality chocolate. + This technique is highly discouraged for use by non-IOCCC judges. + + More often than not, we select a small entry (usually one line), a + strange/creative layout entry. We sometimes also select an + entry that abuses the contest guidelines in an interesting way, + or that stretches the content rules that while legal, is + nevertheless goes against the intent of the rules. + + In the end, we traditionally pick one entry as 'best'. Sometimes such + an entry simply far exceeds any of the other entries. More often, the + 'best' is picked because it does well in a number of categories. + + In years past, we renamed the winning entry from prog.c to a + name related to the submitter(s) names. This is no longer done. + Winning source is called prog.c A compiled binary is called prog. + + +ANNOUNCEMENT OF WINNERS: + + The judges will tweet initial announcement of who won, the name + of their award, and a very brief description of the winning entry + from the @IOCCC twitter handle. Non-twitter users should visit: + + https://twitter.com/ioccc + + Non-twitter users should force their browsers to reload the above URL + to be sure they are seeing the most recent tweets. + + The judges will then post an initial announcement of who won, the name + of their award, and a very brief description of the winning entry + on the IOCCC web site: + + http://www.ioccc.org/whowon.html + + We will also attempt to submit a brief announcement story to /.: + + http://slashdot.org + + that, depending on the willingness of the /. editors, may be posted + to their site at the same time. + + Note that initial announcement will NOT contain source. This is because + the winning authors are given a chance to review the judges comments, + and test our Makefile. This review process typically takes a few weeks. + + Sometime after the initial announcement, and once the review + by the winners has been completed, the winning source will be + posted to the IOCCC web site: + + http://www.ioccc.org/years.html + + NOTE: previous winners are available at that URL + + We will also tweet, via @IOCCC, when the winning source is available. + + It is pointless to ask the IOCCC judges how many entries we receive. + Other government TLA or FLA snooping organizations are prohibited from + either confirming, denying or revealing any knowledge of this data point. + + Often, winning entries are published in selected magazines from around + the world. Winners have appeared in books ("The New Hackers Dictionary") + and on T-Shirts. More than one winner has been turned in a tattoo! + + Last, but not least, winners receive international fame and flames! :-) + + +FOR MORE INFORMATION: + + You may contact the judges by sending email to the following address: + +| q.2019@ioccc.org (do not submit entries to this address) + +| You must include the words 'ioccc 2019 question' in the subject of your + email message when sending email to the judges. + + Questions and comments about the contest are welcome. Comments about + confusing rules and guidelines are also welcome. + + The rules and the guidelines may (and often do) change from year to + year. You should be sure you have the current rules and guidelines + prior to submitting entries. + + Check out the IOCCC Web page: + + http://www.ioccc.org + + It has rules, guidelines and winners of previous contests (1984 to date). + + For the updates and breaking IOCCC news, you are encouraged to follow + the twitter handle: + + @IOCCC + + You do not have to be a twitter user to follow @IOCCC. Non-twitter + users should access: + + https://twitter.com/ioccc + + Non-twitter users should force their browsers to reload the above URL + to be sure they are seeing the most recent tweets. + +Leonid A. Broukhis +Simon Cooper +chongo (Landon Curt Noll) /\cc/\ diff --git a/2019/diels-grabsch1/prog.c b/2019/diels-grabsch1/prog.c index 49eeddb77..a39e29bfa 100644 --- a/2019/diels-grabsch1/prog.c +++ b/2019/diels-grabsch1/prog.c @@ -1,5 +1,5 @@ #include -int main(){int a=0,b=a;long long c[178819],d=8,e=257,f,g, +int main(void){int a=0,b=a;long long c[178819],d=8,e=257,f,g, h,i=d-9;for(;a<178819;){c[a++]=i;}for(a*=53;a;a>>=8)putc\ har(a);if((f=getchar())<0)return 0;for(;(g=getchar())>=0; ){h=i=g<<8^f;g+=f<<8;a=e<(512<256?a:a>6?15