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

Merge pull request #90 from xexyl/bugs

Browse Source 
Rename BUGS.md -> bugs.md and greatly improve it
This commit is contained in:
Landon Curt Noll authored and GitHub committed 2023-03-19 14:01:00 -07:00
2 parents 6908b01215 fd9b44ef76
commit bf4eacac7d
7 files changed
+224 -70
Download Patch File Download Diff File Expand all files Collapse all files

No files matched your search

.gitignore
+1
View File
@@ -28,5 +28,6 @@
/archive/2018/
/archive/2019/
/archive/2020/
/bugs.html
mkentry
iocccsize
1984/decot/README.md
+2 -2
View File
@@ -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
1984/mullender/README.md
+4 -5
View File
@@ -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
1995/cdua/README.md
+5 -2
View File
@@ -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.
1996/westley/README.md
+43 -43
View File
@@ -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.
BUGS.md
-18
View File
@@ -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.
bugs.md
+169
View File
@@ -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 ..