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

Merge branch 'xexyl-updates'

Browse Source 
Complex merge of pull request #7:

Conflicts resolved for:

    .gitignore

A few minor trailing whitespace changes made in:

    faq.html
    2000/guidelines
This commit is contained in:
Landon Curt Noll committed 2023-02-12 18:46:46 -08:00
2 parents 8db60dac97 efa60c592e
commit 0af0de4885
202 files changed
+742 -4069
Download Patch File Download Diff File Expand all files Collapse all files

No files matched your search

2000/Makefile
+1 -1
View File
@@ -27,7 +27,7 @@
# GitHub pull requests are welcome:
#
# If you have a patch that might make running an entry work in modern Unix-like
# environments, please create a GitHub pull request for the IOCCC judgess to
# environments, please create a GitHub pull request for the IOCCC judges to
# consider.
#
# Suggestions and corrections regarding Makefiles, winning author information,
2000/README
+3 -3
View File
@@ -98,11 +98,11 @@ Send such email to:
If you use, distribute or publish these entries in some way, please drop
us a line. We enjoy seeing who, where and how the contest is used.
You must include the words ``ioccc question'' in the subject of your EMail
message when sending EMail to the judges.
You must include the words ``ioccc question'' in the subject of your email
message when sending email to the judges.
If you have problems with any of the entries, AND YOU HAVE A FIX, please
EMail the fix (patch file or the entire changed file) to the above address.
email the fix (patch file or the entire changed file) to the above address.
The next IOCCC is planned to start towards early spring 2001. Watch:
2000/guidelines
+35 -35
View File
@@ -122,8 +122,8 @@ OUR LIKES AND DISLIKES:
compile/link errors for ANSI C compilers. For example, using gcc
local function declarations, such as:
int
main() {
int
main() {
void blah() { printf("blah\n"); }
blah();
}
@@ -148,13 +148,13 @@ OUR LIKES AND DISLIKES:
Avoid using <varargs.h>. Use <stdarg.h> instead.
If you use C preprocessor directives (#define, #if, #ifdef, ...),
the leading '#' must be the first non-whitespace character on a line.
While some broken C preprocessors do not allow whitespace before a
'#', most do.
If you use C preprocessor directives (#define, #if, #ifdef, ...),
the leading '#' must be the first non-whitespace character on a line.
While some broken C preprocessors do not allow whitespace before a
'#', most do.
The exit() function returns void. On some broken systems have exit()
return int. Your entry should assume that exit() returns a void.
The exit() function returns void. On some broken systems have exit()
return int. Your entry should assume that exit() returns a void.
Small programs are best when they are short, obscure and concise.
While such programs are not as complex as other winners, they do
@@ -204,7 +204,7 @@ OUR LIKES AND DISLIKES:
bytes of whitespace, or ; { or } followed by either whitespace
or end of file. [[Q: What is special about 1681?]]
Please do not use things like gzip to get around the size limit.
Please do not use things like gzip to get around the size limit.
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
@@ -215,13 +215,13 @@ OUR LIKES AND DISLIKES:
We suggest that you avoid trying for the 'smallest self-replicating'
source. The smallest, a zero byte entry, won in 1994.
We do not like writable strings. That is, we don't want stuff like:
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.
Please don't make use of this feature, even if your system allows it.
X client entries should be as portable as possible. Entries that
adapt to a wide collection of environments will be favored. Don't
@@ -261,8 +261,8 @@ OUR LIKES AND DISLIKES:
* pass lint without complaint (not a requirement, but it is nice)
* 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 helps!)
* MAKE USE OF A NUMBER OF DIFFERENT TYPES OF OBFUSCATION <== HINT!!
* make us laugh and/or throw up :-) (humor helps!)
Some types of programs can't excel (tm) in some areas. Of course, your
program doesn't have to excel in all areas, but doing well in several
@@ -348,7 +348,7 @@ ENTRY FORMAT:
the entry against the size rules.
If you have any suggestions, comments, fixes or complaints about
the mkentry.c program, please send EMail to the judges. (see below)
the mkentry.c program, please send an email to the judges. (see below)
The following is a sample entry (the | change bars are not part
of the example, don't add them to your entry!)
@@ -573,7 +573,7 @@ end
format may be ignored. That is, don't place text outside of the
entry and expect us to see it. (Our decoding tools are not AI
progs!) If you need tell the judges something, put it in the
---remark--- section, or send a EMail to:
---remark--- section, or send an email to:
questions@ioccc.org (not the address for submitting entries) |
@@ -601,10 +601,10 @@ end
JUDGING PROCESS:
Entries are judged by Leonid A. Broukhis, Jeremy Horn, Landon Curt Noll
and Peter Seebach.
Entries are judged by Leonid A. Broukhis, Jeremy Horn, Landon Curt Noll
and Peter Seebach.
Entries are unpacked into individual directories. The EMail message
Entries are unpacked into individual directories. The email
is unpacked into individual files, each containing:
---entry--- section
@@ -612,7 +612,7 @@ JUDGING PROCESS:
all ---info--- sections
---build--- section
---program--- section
any other text, including the EMail message headers
any other text, including the email headers
Prior to judging, the 'any other text' file is scanned to be sure
it does not contain useful information (or in case the entry was
@@ -634,7 +634,7 @@ JUDGING PROCESS:
we do indicate the volume of paper consumed when presenting the IOCCC
winners at talks)
After the Usenix announcement, we attempt to send EMail to the
After the Usenix announcement, we attempt to send an 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
@@ -723,12 +723,12 @@ ANNOUNCEMENT OF WINNERS:
Winning entries will be posted in June to the following groups: |
comp.lang.c comp.lang.c.moderated alt.sources
comp.lang.c comp.lang.c.moderated alt.sources
In addition, pointers to these postings are posted to the following
comp.sources.misc comp.windows.x comp.programming
misc.misc comp.std.c alt.folklore.computers
comp.sources.misc comp.windows.x comp.programming
misc.misc comp.std.c alt.folklore.computers
Winning entries will be deposited into the uunet archives. See
below for details.
@@ -742,30 +742,30 @@ ANNOUNCEMENT OF WINNERS:
FOR MORE INFORMATION:
You may contact the judges by sending EMail to the following address:
You may contact the judges by sending an email to the following address:
questions@ioccc.org (not the address for submitting entries)
questions@ioccc.org (not the address for submitting entries)
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. To obtain them, send EMail to the address
prior to submitting entries. To obtain them, send an email to the address
above and use the subject 'send rules'.
Check out the IOCCC Web page:
http://www.ioccc.org
http://www.ioccc.org
It has rules, guidelines and winners of previous contests (1984 to date).
It has rules, guidelines and winners of previous contests (1984 to date).
As a last resort, previous winners may be obtained by sending EMail
to questions@ioccc.org. Please use the subject 'send YEAR winners',
where YEAR is a single 4 digit year or a year range (such as 1993-1994),
or the word 'all'.
As a last resort, previous winners may be obtained by sending email
to questions@ioccc.org. Please use the subject 'send YEAR winners',
where YEAR is a single 4 digit year or a year range (such as 1993-1994),
or the word 'all'.
Leonid A. Broukhis
Jeremy Horn
Leonid A. Broukhis
Jeremy Horn
chongo <Landon Curt Noll> /\cc/\
Peter Seebach
Peter Seebach
2000/mkentry.c
+7 -7
View File
@@ -38,7 +38,7 @@
*
* FOR MORE INFORMATION:
*
* You may contact the judges by sending EMail to the following address:
* You may contact the judges by sending an email to the following address:
*
* questions@ioccc.org (not the address for submitting entries)
*
@@ -210,9 +210,9 @@ main(argc, argv)
printf("cases where it conflicts with the rules, the rules shall apply.\n");
printf("It is your responsibility to ensure that your entry conforms to\n");
printf("the current rules.\n\n");
printf("EMail your entries to:\n");
printf("Email your entries to:\n");
printf("\t%s\n\n", ENTRY_ADDR);
printf("Please use the following subject when you EMail your entry:\n");
printf("Please use the following subject when you email your entry:\n");
printf("\tioccc entry\n\n");
/* all done */
return 0;
@@ -605,7 +605,7 @@ output_entry(FILE *output, char *oname)
check_io(output, oname, EOF_NOT_OK);
/* determine if this is a fix */
printf("Is this a fix, update or resubmittion to a ");
printf("Is this a fix, update or resubmission to a ");
printf("previous entry (enter y or n)? ");
while (get_line(buf, 1+1, 0) <= 0 || !(buf[0]=='y' || buf[0]=='n')) {
printf("\nplease answer y or n: ");
@@ -767,7 +767,7 @@ output_author(FILE *output, char *oname)
*/
printf("\nEnter information about each author. If your entry is after\n");
printf("%s and before the contest deadline, the judges\n", START_DATE);
printf("will attempt to EMail back a confirmation to the first author\n");
printf("will attempt to email back a confirmation to the first author\n");
/*
* place author information for each author in an individual section
@@ -803,9 +803,9 @@ output_author(FILE *output, char *oname)
printf("your country and do not include your name.\n");
output_till_dot(output, oname, "addr:");
/* write the EMail address */
/* write the email address */
printf(
"\nEnter the EMail address for author #%d. Use an address from\n",
"\nEnter the email address for author #%d. Use an address from\n",
auth_cnt);
printf(
"a registered domain or well known site. If you give several\n");
2000/rules
+8 -8
View File
@@ -62,7 +62,7 @@ org: School/Company/Organization
addr: postal address
use tab indented lines to continue
don't forget to include the country
email: EMail address from a well known site or registered domain.
email: email address from a well known site or registered domain.
If you give several forms, list them on separate tab indented lines.
url: http://your/home/page.html or say none if you don't have one
anon: y or n (y => remain anonymous, n => OK to publish this info)
@@ -103,7 +103,7 @@ into a file named is 'prog.c'. The resulting file must follow rule #2.
* With the exception of the header, all text outside of the above
format may be ignored by the judges. If you need to tell the judges
something, put it in the ---remark--- section, or send a separate
EMail message to the judges.
email to the judges.
* Information from the ---author--- section will be published unless
'y' was given to the respective author's 'anon' line.
@@ -167,21 +167,21 @@ into a file named is 'prog.c'. The resulting file must follow rule #2.
7) The program must be of original work. All programs must be in the
public domain. All copyrighted programs will be rejected.
8) Entries must be received prior to 31-Mar-2000 23:59:59 UTC. (UTC is
essentially equivalent to Greenwich Mean Time) EMail your entries to:
8) Entries must be received prior to 31-Mar-2000 23:59:59 UTC (UTC is
essentially equivalent to Greenwich Mean Time). Email your entries to:
entry@ioccc.org
We request that your message use the subject 'ioccc entry'.
If possible, we request that you hold off on EMailing your entries
If possible, we request that you hold off on emailing your entries
until 01-Feb-2000 00:00 UTC. Early entries will be accepted, however.
We will attempt to EMail a confirmation to the sender of any entry
We will attempt to email a confirmation to the sender of any entry
received after 01-Feb-2000 00:00 UTC and before the close
of the contest.
9) Each person may submit up to 8 entries per contest year. Each entry
must be sent in a separate EMail letter.
must be sent in a separate email.
10) Entries requiring human interaction to be built are not allowed.
@@ -212,7 +212,7 @@ FOR MORE INFORMATION:
It has rules, guidelines and winners of previous contests (1984 to date).
As a last resort, previous winners may be obtained by sending EMail
As a last resort, previous winners may be obtained by sending email
to questions@ioccc.org. Please use the subject 'send YEAR winners',
where YEAR is a single 4 digit year or a year range (such as 1993-1994),
or the word 'all'.