diff --git a/.gitignore b/.gitignore index ad307c4a3..8fcaf6191 100644 --- a/.gitignore +++ b/.gitignore @@ -28,5 +28,6 @@ /archive/2018/ /archive/2019/ /archive/2020/ +/bugs.html mkentry iocccsize diff --git a/1984/decot/README.md b/1984/decot/README.md index 2c5b7f0a8..8850e2247 100644 --- a/1984/decot/README.md +++ b/1984/decot/README.md @@ -6,8 +6,8 @@ Dave Decot make all -NOTE: [Yusuke Endoh](/winners.html#Yusuke_Endoh) supplied a patch so that this -entry would compile with gcc. +[Yusuke Endoh](/winners.html#Yusuke_Endoh) supplied a patch so that this +entry would compile with gcc. Thank you Yusuke! NOTE: this entry requires a compiler that supports `-traditional-cpp`. Note that clang does not support it and in macOS gcc is actually clang so this will not diff --git a/1984/mullender/README.md b/1984/mullender/README.md index 20c33f1dd..a9238ff1d 100644 --- a/1984/mullender/README.md +++ b/1984/mullender/README.md @@ -12,7 +12,10 @@ Robbert van Renesse ./mullender -NOTE: This entry is likely to fail and/or dump core on modern computers. +> NOTE: If your machine is not a Vax-11 or pdp-11, this program will +> not execute correctly. In later years, machine dependent +> code was discouraged. + ## Judges' comments: @@ -25,10 +28,6 @@ be non machine specific. This program was selected for the 1987 t-shirt collection. -> NOTE: If your machine is not a Vax-11 or pdp-11, this program will -> not execute correctly. In later years, machine dependent -> code was discouraged. - The C startup routine (via crt0.o) transfers control to a location named main. In this case, main just happens to be in the data area. The array of shorts, which has been further obfuscated by use of diff --git a/1995/cdua/README.md b/1995/cdua/README.md index d575125a5..0c8fab7b6 100644 --- a/1995/cdua/README.md +++ b/1995/cdua/README.md @@ -13,8 +13,7 @@ [Cody Boone Ferguson](/winners.html#Cody_Boone_Ferguson) fixed this so that it would work with macOS. Once it could compile it additionally segfaulted under -macOS (it did not under linux) which he also fixed. Thank you Cody for your -assistance! +macOS which he also fixed. Thank you Cody for your assistance! ### To run @@ -24,6 +23,10 @@ assistance! NOTE: on modern systems this might be hard to see it solve it in running time as it goes so quickly but it will still show the result after execution. +NOTE: sometimes the program needs you to press enter a second time to continue +solving the maze. + + ## Judges' comments This could be used as the basis of an a-maze-ing screen exerciser. diff --git a/1996/westley/README.md b/1996/westley/README.md index a7762ebd5..3c14411c6 100644 --- a/1996/westley/README.md +++ b/1996/westley/README.md @@ -17,69 +17,69 @@ ## Judges' comments - Also try: +Also try: sh ./clock2 - And for a good time, try: +And for a good time, try: sh ./clock3 - Time and time again, Brian Westley seems to come up with a winner! - We are amazed at how much is being done with only one relatively - short line. We think you will as well if you take the time to - understand it. +Time and time again, Brian Westley seems to come up with a winner! +We are amazed at how much is being done with only one relatively +short line. We think you will as well if you take the time to +understand it. ## Author's comments - This 1-line program allows various analog ASCII clocks - to print out the time; the ASCII clock is built from - the command line arguments, so many different types of - clocks can be generated. Three different scripts are - supplied to print out a grandfather clock, a mantle - clock that runs backwards, and a linear-style clock. - (they are clock1, clock2, and clock3) +This 1-line program allows various analog ASCII clocks +to print out the time; the ASCII clock is built from +the command line arguments, so many different types of +clocks can be generated. Three different scripts are +supplied to print out a grandfather clock, a mantle +clock that runs backwards, and a linear-style clock. +(they are `clock1`, `clock2`, and `clock3`) - The program makes the following (possibly non-portable) assumptions: +The program makes the following (possibly non-portable) assumptions: - 1) Command line strings can be written to +1. Command line strings can be written to - 2) argv[0] can be written to as if it were a long * +2. `argv[0]` can be written to as if it were a `long *` - 3) The first three elements of the struct * returned by - localtime() are seconds, minutes, hours, and all are ints +3. The first three elements of the struct * returned by localtime() are seconds, +minutes, hours, and all are ints - 4) My sample scripts assume ASCII, though this is not - inherent in the code, just my sample scripts +4. My sample scripts assume ASCII, though this is not inherent in the code, just +my sample scripts - These assumptions are pretty reasonable. 2) can be eliminated - by makes the code larger. +These assumptions are pretty reasonable. 2) can be eliminated +by makes the code larger. - The code is simple; the arguments passed are: +The code is simple; the arguments passed are: prog minute_map hour_map hand_symbol clock_image - The program merely takes the minute (0-59) and the hour (0-23) - values, looks up the offsets in minute_map and hour_map - and writes the hand_symbol for each into the clock_image - string. This string is then printed. +The program merely takes the minute (0-59) and the hour (0-23) +values, looks up the offsets in `minute_map` and `hour_map` +and writes the `hand_symbol` for each into the `clock_image` +string. This string is then printed. - The for() loop starts by calling time() with argv[0], so - the time value (a long) is written into the program name. - The for() control value is argc, which starts at 5, but - the /=2 statement is executed before the test, so the for() - loop is executed twice, with h=2, then h=1 (for hour & minute). +The for() loop starts by calling time() with argv[0], so +the time value (a long) is written into the program name. +The for() control value is argc, which starts at 5, but +the /=2 statement is executed before the test, so the for() +loop is executed twice, with h=2, then h=1 (for hour & minute). - The statement of the for() loop takes the hour or minute - field of the struct returned by localtime() by casting it - to an int* and dereferencing element [h]. It is slightly - smaller to use the trick h[(int*)localtime(*m)] instead of - ((int*)localtime(*m))[h]. +The statement of the for() loop takes the hour or minute +field of the struct returned by localtime() by casting it +to an int* and dereferencing element [h]. It is slightly +smaller to use the trick `h[(int*)localtime(*m)]` instead of +`((int*)localtime(*m))[h]`. - This value is in turn indexed into the hour_map or minute_map - parameter to determine where the 'hand' symbol should be - written into the clock_image. +This value is in turn indexed into the `hour_map` or `minute_map` +parameter to determine where the 'hand' symbol should be +written into the `clock_image`. - Note that the hands move in a quantum fashion; 3:59 looks - deceptively like 2:59, since the hour hand will be at the 3 - position. It won't move until both hands click over at 4:00. +Note that the hands move in a quantum fashion; 3:59 looks +deceptively like 2:59, since the hour hand will be at the 3 +position. It won't move until both hands click over at 4:00. diff --git a/BUGS.md b/BUGS.md deleted file mode 100644 index 8a5da183a..000000000 --- a/BUGS.md +++ /dev/null @@ -1,18 +0,0 @@ -# BUGS and (mis)FEATURES - -There are a number of known problems with IOCCC winners: many of -which have to do with differences between today's compiler environments -and those of today. In some cases the original code has a bug, some -of which were recently discovered. In some cases attempt to port -older code to more modern environments introduced bugs. - -The following is a known list of **BUGS and (mis)FEATURES** in IOCCC winners. - -Can you fix/improve them? You are **VERY WELCOME** to try. -Please submit your fixes fix a [GitHub pull request](https://github.com/ioccc-src/temp-test-ioccc/pulls). - -We will be happy to credit those who submit successful [GitHub pull requests](https://github.com/ioccc-src/temp-test-ioccc/pulls) in the entry's _README.md_. - -## 1984/mullender - -This entry is likely to fail and/or dump core on any computer other. diff --git a/bugs.md b/bugs.md new file mode 100644 index 000000000..1de17f7b7 --- /dev/null +++ b/bugs.md @@ -0,0 +1,169 @@ +# BUGS and (mis)FEATURES + +There are a number of known problems with IOCCC winners: many of +which have to do with differences between today's compiler environments +and those of today. In some cases the original code has a bug, some +of which were recently discovered. In some cases attempt to port +older code to more modern environments introduced bugs. + +The following is a known list of **BUGS and (mis)FEATURES** in IOCCC winners. + +Can you fix/improve them? You are **VERY WELCOME** to try. +Please submit your fixes fix a [GitHub pull request](https://github.com/ioccc-src/temp-test-ioccc/pulls). + +We will be happy to credit those who submit successful [GitHub pull +requests](https://github.com/ioccc-src/temp-test-ioccc/pulls) in the entry's +_README.md_ file. If you're a previous winner we will add a link to your winning +entries in the file (if you're not we can add a link to your personal website if +you have one if you like). + + +## Known bugs that are OK to fix + +### [1995/cdua](1995/cdua/cdua.c) ([README.md](1995/cdua/README.md)) + +This did not compile under macOS and after it did it crashed. +[Cody Boone Ferguson](/winners.html#Cody_Boone_Ferguson) fixed this but he +observed that sometimes the program asks the user to hit return a second time to +resume solving the maze. It does not always happen. It doesn't seem to be +related to making it work under macOS as all that did was removing some invalid +prototypes and use `printf()` instead of the invalid pointer to it (incompatible +type). + + +### [2014/vik](2014/vik/prog.c) ([README.md](2014/vik/README.md)) + +[Cody Boone Ferguson](/winners.html#Cody_Boone_Ferguson) discovered a bug that +shows itself in some cases (it works in others) when working on his [2020 Enigma +machine](2020/ferguson2/prog.c) entry. See his +[README.md](2020/ferguson2/README.md) for details (search for `vik` in the +file). + +He provides a tip in testing the problem: it might help to use the Enigma +machine to find problems as it will allow you to verify what is correct and what +is not. Again see his README.md for details. + +## Compiler specific requirements on type of args to main + +The following entries have a problem in that the args to main() are not of a +specific type due this being allowed in earlier C. This shows itself in some +compilers like clang. Looking at the source code of `clang` there is no way to +override this requirement so these entries will fail to compile with clang. + +Please be aware that gcc under macOS is clang despite the fact it might appear +to be gcc: no symlink and both gcc and clang exist. + +[Cody Boone Ferguson](/winners.html#Cody_Boone_Ferguson) has fixed several but +there are some he has not yet fixed and we welcome your help! + +A tip: in the older days args to main() not given a type were used as ints but +when they're required to be `char **` this can cause a problem. In some cases +Cody was able to use a `char *` inside main() (see +[1989/tromp/tromp.c](1989/tromp/tromp.c) for an example). In other cases he was +able to dereference the pointers to be used like an int. Some might require +additional functions are added. + +For one-liners please keep the file one line! + +You may provide an alt version for the fix as well. + + +### [1989/westley](1989/westley/westley.c) ([README.md](1989/westley/README.md)) + +Although [Cody Boone Ferguson](/winners.html#Cody_Boone_Ferguson) fixed this for +some of the versions that are generated (see below tip) it will not work for +all. He noted that trying to fix it in some cases causes a segfault and in other +cases it fails to generate some of the files (others are okay) at all (empty +files). + +He gives a tip on the problem: main() requires the second, third and fourth arg +to be a `char **`. This didn't use to be the case and some compilers like gcc +don't complain. He was able to get `main()` to be correct BUT a feature is that +it uses ROT13 to decrypt the function `znva` to be main in generated files. +Since that function does not have the correct types when converted to main() it +fails to compile. But as he said changing the type causes either a segfault or +files not generated at all. `ver1`, `ver2` and `ver3` are the problematic ones. +The segfault happens when running the main program. + +This will not be a problem with gcc. + +## INABIAF (it's not a bug it's a feature) + +The following entries should NOT be touched: they are system specific by design +but are noteworthy nonetheless. + + +### [1984/mullender](1984/mullender/mullender.c) ([README.md](1984/mullender/README.md)) + +This entry is likely to fail and/or dump core on any computer other than a +Vax-11 or pdp-11. In 1984 machine dependent code was allowed. + +### [1986/august](1986/august/august.c) ([README.md](1986/august/README.md)) + +This entry is known to segfault after printing its output. It was documented by +the judges and needn't be fixed. + +### [1996/westley](1996/westley/westley.c) ([README.md](1996/westley/README.md)) + +This entry will possibly segfault even when showing the proper output in the +`clock1`, `clock2` and `clock3` scripts. Though this doesn't need to be fixed as +long as it works right it wouldn't hurt to fix it either. + + +### [2019/endoh](2019/endoh/prog.c) ([README.md](2019/endoh/README.md)) + +As a backtrace quine this entry is SUPPOSED to segfault so this should not be +touched either. + +### [2020/ferguson1](2020/ferguson1/prog.c) ([README.md](2020/ferguson1/README.md)) + +There are some things that might appear to be bugs but are actually features or +things that are misinterpreted as bugs. See his +[bugs.md](2020/ferguson1/bugs.md) and +[troubleshooting.md](2020/ferguson1/troubleshooting.md) files for details. + +### ... more to be added later ... + +## Mis-features that should not be fixed + +The following entries should not be touched either as although it might seem +wrong they are not. + +### [1986/holloway](1986/holloway/holloway.c) ([README.md](1986/holloway/README.md)) + +When compiling this entry you might get an incompatible pointer type warning but +this should be ignored. When [Cody Boone +Ferguson](/winners.html#Cody_Boone_Ferguson) fixed this he experimented with the +alternatives and it did not work. Thus if you see something like: + +```c +[holloway.c:15:11: warning: incompatible pointer types initializing 'char *' with an expression of type 'char **'; dereference with * [-Wincompatible-pointer-types] + char *t = s; + ^ ~ + * + +``` + +it is NOT a problem and should not be changed. + +## Entries that require a compiler that support `-traditional-cpp` + +The following entries need a compiler that support `-traditional-cpp`. `gcc` +supports this but `clang` does not. Please be advised that `gcc` under macOS is +actually gcc if it looks like it's gcc (two different binaries). + +- [1984/decot](1984/decot/decot.c) ([README.md](1984/decot/README.md)) +- [1985/sicherman](1985/sicherman/sicherman.c) ([README.md](1985/sicherman/README.md)) +- [1986/wall/wall.c](1986/wall/wall.c) ([README.md](1986/wall/README.md)) +- [1988/dale](1988/dale/dale.c) ([README.md](1988/dale/README.md)) + +.. more to be added as they are discovered .. + + +## Entries that can no longer compile + +.. entries to be added later .. + +## Entries that can compile but crash (sometimes or always) + +.. entries to be added later ..