mirror/ioccc
1
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Update all/README.md

Browse Source 
Make markdown format. This fixes a number of formatting problems
including no links.

Update obfuscate definition to be more modern (yes I used an American
English dictionary for this! :-) ) and also added definition of
obfuscation. Naturally as a logophile I did indeed include the etymology
of both.

Update some text. I tried to keep the historically significance context
in the file but this is a work in progress for sure.

Changed last updated timestamp. As tempting as it was to write '4 April
...' I just used the output of date(1) in my time zone (which happens to
be the same as the original time zone, whatever that might or might not
mean).

Moved copyright stuff to bottom of file so that the casual reader can
see the contest specific information immediately.

I am aware of some improvements that can be made but later on - today or
another day. The changes in particular have to do with
building/compiling entries in modern systems. Grammar might also be
improvable but that's to be determined later on as well.
This commit is contained in:
Cody Boone Ferguson committed 2023-04-04 04:43:32 -07:00
1 parent 1f2c43ac83
commit 4dc8d47ced
1 file changed
+150 -144
Download Patch File Download Diff File Expand all files Collapse all files
all/README.md
+150 -144
View File
@@ -1,176 +1,182 @@
The International Obfuscated C Code Contest # The International Obfuscated C Code Contest
Copyright (c) Landon Curt Noll, Simon Cooper, Peter Seebach *Last updated: Tue Apr 4 04:43:07 PDT 2023*
and Leonid A. Broukhis, 2001-2009.
All Rights Reserved. Permission for personal, educational 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
from the contest judges.
Obfuscate: tr.v. -cated, -cating, -cates. 1. a. To render obscure. ### **Obfuscate** | *verb* [with object]
b. To darken. 2. To confuse: Their emotions obfuscated their
judgment. [LLat. obfuscare, to darken : ob(intensive) + - render obscure, unclear, or unintelligible: the spelling changes will deform
Lat. fuscare, to darken < fuscus, dark.] -obfuscation n. some familiar words and obfuscate their etymological origins.
obfuscatory adj.
- bewilder (someone): it is more likely to obfuscate people than enlighten them.
obfuscatory | adjective
From late Middle English (as adjective): from late Latin obfuscat- 'darkened', from the verb obfuscare, based on Latin fuscus 'dark'.
### **Obfuscation** | *noun*
- the action of making something obscure, unclear, or unintelligible: when
confronted with sharp questions they resort to obfuscation | ministers put up
mealy-mouthed denials and obfuscations.
From late Middle English: from late Latin obfuscatio(n-), from obfuscare 'to darken or obscure' (see obfuscate).
The official IOCCC web site is <https://www.ioccc.org>.
## How it was started:
The original inspiration of the International Obfuscated C Code Contest came
from the Bourne Shell source and the finger command as distributed in 4.2BSD.
If this is what could result from what some people claim is reasonable
programming practice, then to what depths might quality sink if people really
tried to write poor code?
I put that question to the USENET news groups net.lang.c and net.unix-wizards in
the form of a contest. I selected a form similar to the contest
([Bulwer-Lytton](https://www.bulwer-lytton.com)) that asks people to create the
worst opening line to a novel (that contest in turn was inspired by disgust over
[a novel](https://en.wikipedia.org/wiki/Paul_Clifford) by [Edward
Bulwer-Lytton](https://en.wikipedia.org/wiki/Edward_Bulwer-Lytton) that opened
with the line *"It was a dark and stormy night."*). The rules were simple: write,
in 512 bytes or less, the worst complete C program.
Thru the contest I have tried to instill two things in people. First is a
disgust for poor coding style. Second was the notion of just how much utility
is lost when a program is written in an unstructured fashion. Contest winners
help do this by what I call *satirical programming*. To see why, observe one of
the definitions of *satire*:
> Keen or energetic activity of the mind used for the purpose
> of exposing and discrediting vice or folly.
The authors of the winning entries placed a great deal of thought into their
programs. These programs in turn exposed and discredited what I considered to
be the programmer's equivalent of "vice or folly".
There were two unexpected benefits that came from the contest winners. First
was an educational value to the programs. To understand these C programs is to
understand subtle points of the C programming language. The second benefit is
the entertainment value, which should become evident as you read further!
Last updated: Tue Jun 29 13:29:27 PDT 1999 ## Suggestions on how to understand the winning entries:
The official IOCCC web site is: You are strongly urged to try to determine what each program will produce by
visual inspection. Often this is an impossible task, but the difficulty that
you encounter should give you more appreciation for the entry.
https://www.ioccc.org If you have the energy to type in the text, or if you have access to a machine
readable version of these programs, you should next consider some preprocessing
such as:
```sh
sed -e '/^#.*include/d' prog.c | cc -E
```
This strips away comments and expands the program's macros without having things
such as includes and macros cluttering up the output. If the entry requires or
suggests the use of compile line options (such as `-Dindex=strchr`) they should
be added after the `-E` flag. See the entry README.md and/or Makefile. For the
Makefiles look at the variable `CDEFINE`.
The next stage towards understanding is to use a C beautifier or C indenting
program on the source. Be warned that a number of these entries are so twisted
that such tools may abort or become very confused. You may need to help out by
doing some initial formatting with an editor. You might also try renaming
variables and labels to give more meaningful names.
Now try linting the program. You may be surprised at how little lint complains
about these programs. Pay careful attention to messages about unused variables,
wrong types, pointer conversions, etc. But be careful, some lints produce
incorrect error messages or even abort! Your lint may detect syntax errors in
the source. See the next paragraph for suggestions on how to deal with this.
When you get to the stage where you are ready to compile the program, examine
the compilation comments above each entry. A simple define or edit may be
required due to differing semantics between operating systems. If you are able
to successfully compile the program, experiment with it by giving it different
arguments or input. You may also use the Makefile provided to compile the
program. Look at the `To build` and `Try` sections at the top of the README.md
for each entry as well. Keep in mind that C compilers often have bugs, or
features which result the program failing to compile. You may have to do some
syntax changing as we did to get old programs to compile on strict ANSI C
compilers.
Last, read the judges' comments/spoilers on the program. Hints for `foo.c` are
given in `README.md`. Often they will contain suggested arguments or
recommended data to use.
If you do gain some understanding of how a program works, go back to the source
and reexamine it using some of the techniques outlined above. See if you can
convince yourself of why the program does what it does.
How it was started: ## Regarding the source archive:
The original inspiration of the International Obfuscated C Code Each sub-directory contains all the entries for a single year. Often the file
Contest came from the Bourne Shell source and the finger command as names match one of the last names of the author. Judges' hints are given in
distributed in 4.2BSD. If this is what could result from what some files of the form `README.md`.
people claim is reasonable programming practice, then to what depths
might quality sink if people really tried to write poor code?
I put that question to the USENET news groups net.lang.c and You may need to tweak the Makefile to get everything to compile correctly. Read
net.unix-wizards in the form of a contest. I selected a form similar the README.md files for suggestions.
to the contest (Bulwer-Lytton) that asks people to create the worst
opening line to a novel. (that contest in turn was inspired by disgust
over a novel that opened with the line "It was a dark and stormy
night.") The rules were simple: write, in 512 bytes or less, the worst
complete C program.
Thru the contest I have tried to instill two things in people. First
is a disgust for poor coding style. Second was the notion of just how
much utility is lost when a program is written in an unstructured
fashion. Contest winners help do this by what I call satirical
programming. To see why, observe one of the definitions of satire:
Keen or energetic activity of the mind used for the purpose
of exposing and discrediting vice or folly.
The authors of the winning entries placed a great deal of thought into
their programs. These programs in turn exposed and discredited what I
considered to be the programmer's equivalent of "vice or folly".
There were two unexpected benefits that came from the contest winners.
First was an educational value to the programs. To understand these C
programs is to understand subtle points of the C programming language.
The second benefit is the entertainment value, which should become
evident as you read further!
Suggestions on how to understand the winning entries:
You are strongly urged to try to determine what each program will
produce by visual inspection. Often this is an impossible task, but
the difficulty that you encounter should give you more appreciation
for the entry.
If you have the energy to type in the text, or if you have access to
a machine readable version of these programs, you should next consider
some preprocessing such as:
sed -e '/^#.*include/d' program.c | cc -E
This strips away comments and expands the program's macros without
having things such as <stdio.h> macros clutter up the output. If the
entry requires or suggests the use of compile line options (such as
-Dindex=strchr) they should be added after the '-E' flag.
The next stage towards understanding is to use a C beautifier or C
indenting program on the source. Be warned that a number of these
entries are so twisted that such tools may abort or become very
confused. You may need to help out by doing some initial formatting
with an editor. You might also try renaming variables and labels to
give more meaningful names.
Now try linting the program. You may be surprised at how little lint
complains about these programs. Pay careful attention to messages
about unused variables, wrong types, pointer conversions, etc. But be
careful, some lints produce incorrect error messages or even abort!
Your lint may detect syntax errors in the source. See the next
paragraph for suggestions on how to deal with this.
When you get to the stage where you are ready to compile the program
examine the compilation comments above each entry. A simple define or
edit may be required due to differing semantics between operating
systems. If you are able to successfully compile the program,
experiment with it by giving it different arguments or input.
You may also use the makefile provided to compile the program.
Keep in mind that C compilers often have bugs, or features which
result the program failing to compile. You may have to do some
syntax changing as we did to get old programs to compile on strict
ANSI C compilers.
Last, read the judges' comments/spoilers on the program. Hints
for `foo.c` are given in `README.md`. Often they will contain suggested
arguments or recommended data to use.
If you do gain some understanding of how a program works, go back to
the source and reexamine it using some of the techniques outlined above.
See if you can convince yourself of why the program does what it does.
Regarding the source archive:
Each sub-directory contains all the entries for a single year. Often
the file names match one of the last names of the author. Judges'
hints are given in files of the form `README.md`.
You may need to tweak the Makefile to get everything to compile correctly.
Read the README.md files for suggestions.
The rules for a given year are given in the file named `rules.txt`. Each The rules for a given year are given in the file named `rules.txt`. Each
archive contains a copy of the rules for the upcoming contest. archive contains a copy of the rules for the upcoming contest.
The following URL is the official archive of the winning entries: The following URL is the official archive of the winning entries:
<https://www.ioccc.org/years.html>.
https://www.ioccc.org/years.html
Regarding the distribution of sources: Regarding the distribution of sources:
All contest results are in the public domain. We do ask that you observe All contest results are in the public domain. We do ask that you observe the
the following request: following request:
You may share these files with others, but please do not prevent them of You may share these files with others, but please do not prevent them of
doing the same. If some of these files and/or contest entries are doing the same. If some of these files and/or contest entries are
published in printed form, or if you use them in a business or classroom published in printed form, or if you use them in a business or classroom
setting, please let us know. We ask that you drop a line to the setting, please let us know. We ask that you drop a line to the
'judges' email box. See the following page for instructions on judges' email box. See <https://www.ioccc.org/contact.html> for instructions on
how to send us a message, how to send us a message:
https://www.ioccc.org/contact.html ## Some final things to remember:
Some final things to remember: While the idea for the contests has remained the same through the years, the
contest rules and guidelines vary. What was novel one year may be considered
common the next. The categories for awards differ because they are determined
after the judges examine all of the entries.
While the idea for the contests has remained the same through the The judges' hints assume that the program resides in a file with the same
years, the contest rules and guidelines vary. What was novel one year username as the author or `prog.c` (depending on the year). Where there is more
may be considered common the next. The categories for awards differ than one author, the first named author is used. If an author wins more than
because they are determined after the judges examine all of the one entry per year there are different formats used but the most recent one is
entries. the first entry has 1 appended, the second has 2 etc.
The judges' hints assume that the program resides in a file with the Some C compilers are unable to compile some of these programs. The judges tried
same username as the author. Where there is more than one author, the to select programs that were widely portable and compilable, but did not always
first named author is used. succeed. As of 1990, an entry may use both `K&R` and ANSI C compilers.
Makefiles for both types of C compilers are used. See the contest rules for
details.
Some C compilers are unable to compile some of these programs. The You are strongly encouraged to read the new contest rules before sending any
judges tried to select programs that were widely portable and entries. The rules, and sometimes the contest email address itself, change from
compilable, but did not always succeed. As of 1990, and entry time to time. A valid entry one year may be rejected in a later year due to
may use both ``K&R'' and ANSI C compilers. Makefiles for both changes in the rules. See <https://www.ioccc.org/index.html#enter> for up to
types of C compilers are used. See the contest rules for details. date information on how to enter.
You are strongly encouraged to read the new contest rules before Last, PLEASE don't code in the style of these programs It is hoped that you will
sending any entries. The rules, and sometimes the contest email gain an understanding that poor style destroys an otherwise correct program.
address itself, change from time to time. A valid entry one year may Real programmers don't write obfuscated programs, unless they are submitting a
be rejected in a later year due to changes in the rules. See: contest entry! :-)
https://www.ioccc.org/index.html#enter
for up to date information on how to enter.
Last, PLEASE don't code in the style of these programs It is hoped that
you will gain an understanding that poor style destroys an otherwise
correct program. Real programmers don't write obfuscated programs,
unless they are submitting a contest entry! :-)
Happy pondering! Happy pondering!
## Copyright
Copyright(c) Landon Curt Noll, Simon Cooper, Peter Seebach
and Leonid A. Broukhis, 1984-2023.
All Rights Reserved. Permission for personal, educational 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
from the contest judges.