diff --git a/bugs.html b/bugs.html index 0a074ad5d..9125656ab 100644 --- a/bugs.html +++ b/bugs.html @@ -443,14 +443,13 @@ might seem to be fine but is actually not! We will note some where this is known to happen (if it’s not yet fixed). This has actually already happened to us. Sometimes it is okay: some entries are known to not work but they can still have improvements (rarer situation but it’s happened). Some might have slightly -different output but which is not a problem for instance a newline after output -in Cody Boone Ferguson’s changing it to -1994/ldb use fgets() from gets().

+different output but which is not a problem for instance a newline after output. +This is not the most ideal but it is okay.

Make ABSOLUTE CERTAIN that you read the index.html file BEFORE your changes as it’s important to see that the code is doing what it is supposed to. In the case that it’s not obvious (some index.html files do not even have commands to try or even explain how to use it!) then you should either skip the entry OR ask -someone who will know e.g. us.

+someone who will know for instance the Judges.

Make ABSOLUTE CERTAIN that you read the next section, the list of statuses and the related information, BEFORE you submit a pull request!

BE VERY AWARE that sometimes fixing an entry for one platform will break it @@ -480,17 +479,17 @@ different warnings.

sizes on different platforms. These tend to be required at the risk that sometimes the entry will not work for certain platforms, some of which might or might not be fixable; a good example where it was required to change and is okay -is when Cody Boone Ferguson fixed the -segfault in macOS of 1989/paul: changing the int * to a -long * was required and it works just as well with linux.

+is the fix of the segfault in macOS of +1989/paul: changing the int * to a long * +was required and it works just as well with linux.

But even if they are fixable (which will likely be hard to do) it’s almost certain that such code would be just as non-portable (importable ? :-) ).

-

In rare cases they are valid. For instance Cody noticed in linux the following +

In rare cases they are valid. For instance in linux the following warning in 1985/applin with gcc:

    applin.c:1:78: warning: incompatible implicit declaration of built-in function 'execlp' [-Wbuiltin-declaration-mismatch]
         1 | main(v,c)char**c;{for(v[c++]=strdup("Hello, world!\n");(!!c)[*c]&&(v--||--c&&execlp(*c,*c,c[!!c]+!!c,!c));**c=!c)write(!!*c,*c,!!**c);}
           |                                                                              ^~~~~~
-

and this reminded him of his fix to +

and this is is kind of like the fix to 1984/anonymous. In the case of 1984/anonymous it was a bit more involved but with 1985/applin one need only add to the Makefile -include unistd.h. So there are some cases where fixing warnings can fix a @@ -507,14 +506,14 @@ include you can update the Makefile CINCLUDE variable. For instance needs stdio.h you could do -include stdio.h. Please leave a space after the = in the Makefile. You may also have extra long lines if this seems useful to make it a one-liner even if it kind of makes it longer than what the judges -consider a one-liner. Thank you!

+consider a one-liner, at least within reason. Thank you!

On layout of program source:

If you make changes PLEASE TRY AND KEEP THE SOURCE CODE LAYOUT AS CLOSE TO THE ORIGINAL AS POSSIBLE. This might not always be possible and if you have an editor that does formatting it can cause problems. Sometimes formatters can even -break code! Cody Boone Ferguson has -experienced this many times with vim so he tends to disable all format options -when formatting code. In vim you should be able to do that with:

+break code! Some have experienced this many times with vim so he tends to +disable all format options when formatting code. In vim you should be able to do +that with:

    :set formatoptions=

STATUS: known bug

Please help us fix!

@@ -564,7 +563,7 @@ much as possible given the nature of how it generates code: the entry itself compiles but two versions of code it generates does not work with clang.

However some still might have problems of some kind or another and some might not yet be located as an additional defect of clang was noticed where main() -is not allowed four args or one arg.

+is not allowed four args or one arg (see below).

This is what the status means, however.

Entries with this status have a problem in that the args to main() are not of a specific type or there are too many due to this being allowed in earlier C. Some @@ -572,24 +571,24 @@ compilers like clang have a defect where they do not allow this and some versions have an additional defect where they only allow 0, 2 or 3 args, the latter of which affected 1989/westley, so these entries do not work with clang.

-

Cody Boone Ferguson looked at the source -code of clang and reported that there is no way to override the requirement of +

Looking at the source +code of clang, it appears that there is no way to override the requirement of arg types so these entries will fail to compile with clang. That’s why in some -entries he fixed he did it by adding a function called pain(). :-) He did not -check for the number of args as that was discovered later but he suspects it’s -the same issue.

+entries the fix was done with a new function, often called pain() :-)

NOTE for macOS users: please be aware that gcc under macOS is actually clang despite the fact it might appear to be gcc: no symlink and both gcc and clang exist but the gcc is clang which you’ll see if you run gcc --version.

-

A tip and some fix methods from Cody: in the older days args to main() not given -a type were implicit 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 and -1986/holloway/holloway.c for two examples though done slightly -differently). In other cases he was able to dereference the pointers to be used -like an int and other times a cast was necessary. He used other various -techniques to get them to compile. In some cases this introduced a problem but -typically if not always that problem exists with compilers that are less strict.

+

A tip and some fix methods from Cody Boone +Ferguson: in the older days args to main() +not given a type were implicit ints but when they’re required to be char ** +this can cause a problem. In some cases it was possible to use a char * inside +main() (see 1989/tromp/tromp.c and +1986/holloway/holloway.c for two examples though +done slightly differently). In other cases it was possible to dereference the +pointers to be used like an int and other times a cast was necessary. There are +various techniques to get these to compile. In some cases this introduced a +problem but typically if not always that problem exists with compilers that are +less strict.

STATUS: main() has only one arg

Please help modify so that main() as 2 or 3 args!

Because some versions of clang complain about the number of args of main() and @@ -611,37 +610,35 @@ or if you can -ggdb3 when compiling as that will help with debuggin

STATUS: uses gets()

Please help us change use of gets() to fgets(), if possible.

Entries with this status use gets() which is unsafe because it has no limit on -the length of the string. Cody Boone -Ferguson has fixed several of these and he’s -working on others in between fixing other things.

-

There’s a very good reason for this even though it is bordering on tampering +the length of the string. Many were fixed but not all.

+

There’s a very good reason for this change even though it is bordering on tampering entries: in modern systems one will get possibly alarming and certainly annoying warnings during at least one of compiling, linking and execution. In macOS it’s most annoying as it happens during execution (also compilation) with the warning being interspersed with the output of the program, often causing confusing output with the entry. A good example that was fixed is 1990/tbr.

-

Cody provided some important notes on this status with respect to fixing / -changing entries:

+

Some important notes on this status with respect to fixing / changing the +entries:

  1. In some cases changing the entry to use fgets() will break the entry and in -some cases cause it to crash. Where this is known we will document it. Some of -these Cody is also off and on working on.

    2. +some cases cause it to crash. Where this is known we will document it.

  2. You MUST check the output before and after to make sure that it remains the same. Sometimes the output might not be immediately obviously wrong but is. We will document known examples as we come across them.

  3. gets() does NOT STORE the '\n' but fgets() DOES! This is one of the -reasons some of the entries break when changed to fgets(). Cody has fixed some -of these but there are others he hasn’t had time to address or even discover -yet.

    4. +reasons some of the entries break when changed to fgets(). Some of those have +been fixed but there are others that have not been.

  4. Just because you don’t see the string gets in the code does not mean it’s not used. It is after all the International Obfuscated C Code Contest! :-) Sometimes it will be in the Makefile and other times it will be obfuscated in -other ways. Compilers and linkers tend to warn about its use (and as noted in -macOS it also happens at execution) and this is a good way to find entries that -use it even if it’s not visible in the code.

    5. +other ways; a good example of that that was fixed is +1991/dds: in this case the string was encrypted. +Compilers and linkers tend to warn about its use (and as noted in macOS it also +happens at execution) and this is a good way to find entries that use it even if +it’s not visible in the code.

-

NOTE: this status is NOT necessarily mutually exclusive with the INABIAF +

NOTE: this status is NOT necessarily mutually exclusive with the INABIAF (it’s not a bug it’s a feature) status. The reason for this is due to warnings during compiling, linking and/or runtime, sometimes causing confusing output (as noted above).

@@ -733,16 +730,17 @@ code. In particular you should see something like:

STATUS: INABIAF - please DO NOT fix

Source code: 1984/mullender/mullender.c

Information: 1984/mullender/index.html

-

Although there is an alt version and supplementary program added by Cody that +

Although there is an alt version and supplementary program added, that will work in modern systems, if you do not have a VAX-11 or PDP-11 to run the original entry on it will not work. See the index.html for details on the alternate versions.

-

Cody added and fixed the gentab.c which is from the -author’s (or one of them, Mullender) remarks found by Cody. Cody fixed this to -compile and work (as best as he can determine: he has no VAX-11 or PDP-11 or -emulator to test it) but running the code on the binary itself produces a -short[] that can compile in modern systems though it’ll not work.

+

The file gentab.c which is from the +author’s (or one of them, Mullender) remarks, was fixed for modern systems, at +least as best as can be determined: running the code on the binary itself does +produce a short[] that can compile in modern systems but it will not work. +Before the fix it would fail in some cases and it is possible that in some cases +it might still fail.

1985

@@ -823,8 +821,10 @@ reverse of other code (also wrt names). See the source file and the index.html (in the author’s remarks) for more details.

Fixing the (mis)feature is likely to be a very difficult challenge especially without breaking something else which is far more likely (see below in tips from -Cody). You are welcome to try and fix it if you can!

-

Tips from Cody:

+Cody, who fixed it so the original would compile with clang and at least one +generated version would compile with clang too, not compromising the other +versions with gcc). You are welcome to try and fix it if you can!

+

Tips:

The reason this is crashing is that the array irk is being accessed way out of bounds by the int gnat. For instance:

    Program terminated with signal SIGSEGV, Segmentation fault.
@@ -836,12 +836,11 @@ bounds by the int gnat. For instance:

 
Magic of the entry:

 
The real trouble is that the code is generated and in a complex way or rather
 ways.

-
I will explain this a little bit (though it might be more than a bit according
-to many :-) ) but that is all I can do for now. The program, when used without
-any args, will print out what it reads. If one arg is specified it will do a
-ROT13 of it. If two args are specified it will print out the text backwards
-(WITHOUT ROT13!). If three args are specified it will do both reversal AND
-ROT13.

+
Trying to explain this might be tricky but here is an attempt. The program, when
+used without any args, will print out what it reads. If one arg is specified it
+will do a ROT13 of it. If two args are specified it will print out the text
+backwards (WITHOUT ROT13!). If three args are specified it will do both
+reversal AND ROT13.

 
So ver0 is the same as the main program; ver1 is the ROT13 of the code (but
 see below); ver2 will reverse the code and ver3 will both reverse and ROT13
 the code. But it’s trickier than that as one might expect.

@@ -879,19 +878,17 @@ just the reversal version, of course but ver1 is the ROT13 version.

 and then another version that has the reversal and ROT13 then you can see it’s
 nigh impossible to fix if not impossible.

 
The fix to get it to even compile with clang and then get the first two
-(counting the original, ver0) to work was the hardest fix I made due to how
-the comments in reverse and ROT13 of it all works together, especially allowing
-all versions to compile with gcc. The only reason that it doesn’t work
-completely with clang is the arg types of main() (see if you can figure out how
-the change of main() in westley.c is not carried over to versions 2 and 3!);
-originally none of them compiled with clang.

+(counting the original, ver0) to work was quite hard due to how the comments
+in reverse and ROT13 of it all works together, especially allowing all versions
+to compile with gcc. The only reason that it doesn’t work completely with clang
+is the arg types of main() (see if you can figure out how the change of main()
+in westley.c is not carried over to versions 2 and 3!); originally none of
+them compiled with clang.

 
But it was possible to get the ROT13 code to compile with clang but the other
 versions, reversed as well as ROT13 and reversed code, proved much more
-problematic. I got it to compile (or maybe mostly compile) all versions with
-clang but I then carried it over to gcc in another system and it had syntax
-errors.

-
That’s about all I can say for how it works as other things have to be done too.
-Enjoy! :-)

+problematic. It is now possible to compile (or maybe mostly compile) all versions with
+clang but on another system and it had syntax errors.

+
Enjoy! :-)

 

 

 
1990

@@ -968,11 +965,10 @@ more time and resources to run as well. For instance:

 
STATUS: known bug - please help us fix

 
Source code: 1990/jaw/jaw.c

 
Information: 1990/jaw/index.html

-
Cody Boone Ferguson
-fixed some issues in this program and Yusuke
-Endoh provided the btoa
-script but it appears there is a bug in this entry. The judges wrote that to
-test the entry one can do:

+
Some issues in this program were fixed and Yusuke
+Endoh then provided the btoa script but it appears
+there is a bug in this entry. The judges wrote that to test the entry one can
+do:

 
    echo "Quartz glyph jocks vend, fix, BMW." | compress | ./btoa | ./jaw

 
which should apply the identity transformation to a minimal holoalphabetic
 sentence.

@@ -1011,18 +1007,18 @@ defeat the purpose. This would ideally be fixed.

 
STATUS: INABIAF - please DO NOT fix

 
Source code: 1990/theorem/theorem.c

 
Information: 1990/theorem/index.html

-
Cody Boone Ferguson fixed many bugs that
-prevented this from working properly (including segfaults) but one thing to note
-is that if you pass two zeroes to theorem_bkp or fibonacci the program
-will enter an infinite loop, printing 0 over and over again; another condition
-where this occurred was fixed but this one should not be fixed. Thank you.

+
Many bugs that prevented this from working properly (including segfaults) were
+fixed but one thing to note is that if you pass two zeroes to theorem_bkp or
+fibonacci the program will enter an infinite loop, printing 0 over and over
+again; another condition where this occurred was fixed but this one should not
+be fixed.

 

 
1990/westley

 

 
STATUS: INABIAF - please DO NOT fix

 
Source code: 1990/westley/westley.c

 
Information: 1990/westley/index.html

-
Although Cody fixed this to not enter an infinite loop if the arg (converted to
+
Although this was fixed to not enter an infinite loop if the arg (converted to
 a number) is < 0 the lack of an arg check at all was kept in to make it like the
 original. The reason for the < 0 check is it floods the screen (yes this is
 indeed inconsistent with some other entries but it is not worth the time spent,
@@ -1067,9 +1063,8 @@ when you’re cheating it ends up winning! Can you figure that out as well?

 
Source code: 1992/adrian/adrian.c

 
Information: 1992/adrian/index.html

 
The author stated that if the file cannot be opened then it will print a system
-error but this is not the case unless it’s showing a fault. However this was
-instead fixed by Cody as part of another problem that was detected so that the
-program just exits 1 if the file cannot be opened.

+error but this is not the case unless it’s showing a fault. This was fixed as
+part of another problem that was detected.

 
Also, if some of the programs are not given an arg they will very likely crash
 or do something funny. For instance adsleep and adbasename. This is very
 simple to fix but the author explicitly noted that this will segfault and it is
@@ -1103,7 +1098,7 @@ in albert.orig.c that has been fixed in albert.c,

 Both albert and albert.orig loop without printing anything, although
 the first factor is 101 and is usually found in an instant.

 
-
A quick debugging session from Cody suggests that the problem with this value
+
A quick debugging session suggests that the problem with this value
 is that:

 
    if ( ppp->qq!=48 ) return;

 
is never reached because the value is never 48 (it is in other cases but not for
@@ -1170,13 +1165,13 @@ click the mouse it takes it back towards the centre.

 
STATUS: doesn’t work with some compilers - please provide alternative code or fix for more compilers

 
Source code: 1992/lush/lush.c

 
Information: 1992/lush/index.html

-
We used a patch from Yusuke Endoh to get this to
-work but it only works with gcc. Cody removed the warnings of gets() and
-provided a script to run the entry properly.

+
This was fixed but it only properly works with gcc; it was also changed to use
+fgets() instead of gets() and a script was provided to run the entry
+properly. Nonetheless it will only work with gcc.

 
Unfortunately due to the way the entry works and the fact that other compilers
 like clang have different warnings and errors this simply does not work with
 them.

-
Some tips from Cody:

+
Some tips:

 
This entry relies on specific compiler warnings. With gcc it will look something
 like:

 
    [...]
@@ -1244,7 +1239,7 @@ it yourself through ctrl-c or killing it in some other fashion.

 
STATUS: INABIAF - please DO NOT fix

 
Source code: 1992/westley/westley.c

 
Information: 1992/westley/index.html

-
Cody improved the usability of this program by making it so that as long as the
+
The usability of this program was improved by making it so that as long as the
 terminal columns is >= 80 it will display properly, rather than having to wrap
 at 80 columns. However due to the nature of the program if the terminal is < 80
 in column width it will not display right. To see the number of columns in your
@@ -1359,12 +1354,12 @@ there.

 
STATUS: INABIAF - please DO NOT fix

 
Source code: 1994/ldb/ldb.c

 
Information: 1994/ldb/index.html

-
Cody Boone Ferguson fixed this to compile
-with modern systems but the entry also used gets(3) which in some systems would
-print out a warning along with the output of the program. Naturally it could
-also overflow long lines, of which there are many, though that is more
-considered a feature, not a bug, as it was documented by the author.

-
Cody changed it to fgets(3) to prevent the display problem but this introduces
+
This was fixed to compile with modern systems but the entry also used gets(3)
+which in some systems would print out a warning along with the output of the
+program. Naturally it could also overflow long lines, of which there are many,
+though that is more considered a feature, not a bug, as it was documented by the
+author.

+
It was changed to use fgets(3) to prevent the display problem but this introduces
 another problem namely that newlines can be printed if the line length < 231.

 
This seems like a worthy compromise to not have messed up output and although it
 would be ideal for it to never print a newline (unless that’s the line itself)
@@ -1383,28 +1378,26 @@ for more information on the change to fgets(3).

 even when it works. See the author’s remarks in the index.html for details.
 Increasing the buffer size and having it, when fed its own source code,
 generate code that will compile with the same buffer size is difficult: it just
-uses the original size. Cody explains this further down.

+uses the original size. This is explained later down.

 
Getting it to use fgets() is even harder as when fed its own code it will
 generate code that cannot even compile let alone use fgets(3).

 
In both cases, changing the buffer size and changing it to use fgets(3), will
 cause compilation errors without other adjustments.

 
See the below magic for details. Along with the author’s remarks in the
-index.html file it might prove possible to get it to use fgets(3). Cody,
-writing this on 02 November 2023, only just noticed the author’s remarks and
-will later on look at this if nobody takes up the challenge. More important work
-like getting to a place that the next contest can run must be done first.

-
Cody explains the magic of how this entry works, which will be necessary if this
-entry is to be fixed, below.

-
You might wish to run the command:

-
    make diff_orig_prog

-
to see what had to change for the buffer size, when looking at the below.
-Furthermore you will want to look at:

-
    diff schnitzi.alt.c schnitzi.alt2.c

-
as the fgets(3) version can compile it just can’t generate compilable code (let
-alone using fgets(3)) when fed itself (to reiterate, just changing the call to
-fgets(3) does not mean it can compile and there’s a further problem in that
-fgets(3) retains the newline whereas gets(3) does not). Nevertheless looking
-at these commands will be of help to understand how it works.

+index.html file it might prove possible to get it to use fgets(3).

+
Here is the magic of how this entry works, to help anyone who wishes to work on
+this.

+
You might wish to run the commands:

+
    diff schnitzi.alt.c schnitzi.alt2.c
+
+    diff schnitzi.alt2.c schnitzi.alt.c

+
to see how the buffer size and how the gets(3) was changed to use fgets(),
+in the two alternate versions. Notice that the fgets(3) version can compile it
+just can’t generate compilable code (let alone using fgets(3)) when fed
+itself (to reiterate, just changing the call to fgets(3) does not mean it can
+compile and there’s a further problem in that fgets(3) retains the newline
+whereas gets(3) does not). Nevertheless looking at these commands will be of
+help to understand how it works, in case one wishes to try and fix it.

 
For the alternate versions the other functionality is unaffected.

 
The magic of 1994/schnitzi and how it flips text

 
The problem is getting the generated code to use fgets() (once it even
@@ -1450,9 +1443,9 @@ changing the buffer size, see below).

 
Getting this entry to use fgets(3) is easy but the problem is you’re supposed
 to be able to feed the source to the program and the output of that will be
 compilable. It however will create compiler errors. So it’s not just changing
-the code to get it to use fgets(3)! I (Cody) already did this before I noticed
-the other part which is why I rolled that part back. I did increase the buffer
-size but that only works on the original source.

+the code to get it to use fgets(3)! This was done but
+the other part is why that part was rolled back. The buffer size was increased
+but that only works on the original source.

 
To say just how sensitive this entry is: even a space, lack of space or a
 character, wrong character, lack of character or character in the wrong place
 can cause a compilation error! Make sure that the output of:

@@ -1468,7 +1461,7 @@ compiled!

 
This program will likely crash if the source code file (by the name of the file
 that’s compiled) cannot be opened in the directory it is run from.

 
Important reminder and a note about the -1 value check for getc():

-
Cody fixed the code to not use -1 for the return value of getc(); this is
+
This code was fixed to not use -1 for the return value of getc(); this is
 important because EOF is NOT guaranteed to be -1 but rather any negative
 value. On systems where EOF != -1 the program would enter an infinite loop
 until the program crashed, by chance reads a -1 or was killed (it is for this
@@ -1515,8 +1508,7 @@ as documented, are considered features.

 
Source code: 1995/cdua/cdua.c

 
Information: 1995/cdua/index.html

 
This did not originally compile under macOS and after it did compile under
-macOS, it crashed. Cody Boone Ferguson
-fixed these problems.

+macOS, it crashed. These problems were fixed.

 
It should be noted however that there is a condition where the program will
 prompt you to press return again. This was thought to be a bug but looking at
 the code it can clearly be seen that if g - a is 0 then the message is
@@ -1754,7 +1746,7 @@ with things but we don’t know.

 
    $ echo poot | ./dlowe
     poot was here!

 
Can you help fix these problems?

-
Cody provided the C code that creates an unformatted perl script that will just
+
Here is some C code that creates an unformatted perl script that will just
 print ‘unimplemented’ for operators but it seems to work in some other ways (see
 below for how to go further than unimplemented) which is the exact perl from the
 C program except that it has the #!/usr/bin/env perl and use warnings; as
@@ -1834,18 +1826,17 @@ For instance inputting D followed by XX:

 
That means then that in linux despite the subroutines seemingly not existing it
 works in the code, at least in some cases.

 
As far as the unimplemented error goes: the author stated that it means there is
-invalid input. But as can be seen by the input I (Cody) gave the input is not
+invalid input. But as can be seen by the input given, the input is not
 actually incorrect. It is also curious to note that it ends up printing what’s
 on the stack at that point:

 
    $ echo 5 5 + p | ./dlowe.pl
     unimplemented
     5

-
which might (?) suggest that the + operator is unimplemented. Unfortunately it
-has been many years since I have used perl and I was never a guru either.

+
which might (?) suggest that the + operator is unimplemented.

 
STATUS: INABIAF - please DO NOT fix

 
The author states that in perl < 5.6.0 there is a bug with a core dump in what
 they said is in Perl_sv_upgrade. As this is documented it is not considered a
-bug to be fixed. For the curious this will crash in macOS. Cody notes that the
+bug to be fixed. For the curious this will crash in macOS. It was noted that the
 code that crashes is:

 
    perl_eval_sv
     (newSVpv("_:$_=               <> ; defined               or exit; @ARGV"
@@ -1919,16 +1910,17 @@ fire! :-) ).

 
STATUS: INABIAF - please DO NOT fix

 
Source code: 2001/anonymous/anonymous.c

 
Information: 2001/anonymous/index.html

-
Cody Boone Ferguson fixed this so that it
-doesn’t segfault and then also fixed the functionality of it (but see below).

-
Cody also fixed the anonymous.ten.c program
-(it also segfaulted) but notes that it MUST be compiled as a 32-bit ELF
+
This was fixed so that it doesn’t segfault and then also fixed the functionality
+of it (but see below).

+
The anonymous.ten.c program was
+also fixed (it also segfaulted) but note that it MUST be compiled as a 32-bit ELF
 binary so it will NOT work in macOS (for example); if you cannot use -m32 or
 even if you can but it cannot compile as an ELF binary (not elf binary :-) )
 (but see below) then the anonymous program itself will very likely crash if
-you run it on the compiled anonymous.ten.c but
-if nothing else it will not modify the target executable (this part of the fix
-at least should be correct).

+you run it on the compiled
+anonymous.ten.c; if nothing else
+it will not modify the target executable (this part of the fix at least should
+be correct).

 
Note also that if you don’t specify a file or you specify a non-32-bit ELF file
 this program will very likely crash or do something strange like slaughter the
 elves of Imladris :-(

@@ -1940,36 +1932,35 @@ elves of Imladris :-(

 
Information: 2001/bellard/index.html

 
The author stated that it only works with i386 linux so the fact it doesn’t work
 in modern systems is considered a feature and not a bug.

-
Cody Boone Ferguson fixed an initial
-segfault (trying to open the file) and he also fixed the supplementary program
-bellard.otccex.c but this still crashes in
-systems not i386 linux which is what the author stated.

+
An initial segfault was fixed (trying to open the file) and the supplementary
+program bellard.otccex.c was also
+fixed but this still crashes in systems not i386 linux which is what the author
+stated.

 
The author said that they compiled it with gcc version
 2.95.2. We
 don’t know if a certain gcc version is necessary but it might be helpful to
 download and compile that version to test it - or it might not.

-
I (Cody) have no i386 system to test this but perhaps this is why I can’t get it
-to work. Yusuke was able to get this to work with -m32 but only in an
-emulator.

+
Yusuke was able to get this to work with -m32 but only in an emulator. As
+such, it might be that the changes made should be rolled back but at least now
+the supplementary program will work in modern systems.

 
On the author’s web page for this program it is
 explicitly stated that it requires i386 linux.

-
There I found what should be a more portable version which is included as
-otccelf.c (after adding some #includes and the
-modification by Yusuke noted in the thanks
-file) but it appears this also requires i386 linux; indeed looking at the code
-it hard codes paths that are i386 specific to linux.

+
There it was found what should be a more portable version which is included as
+otccelf.c (after adding some #includes
+and the modification but it appears this also requires i386 linux; indeed
+looking at the code it hard codes paths that are i386 specific to linux.

 
Another point of interest is that the author provided unobfuscated versions
 which might be of value to look at.

 
Aside: why were there changes made if INABIAF ?

 
This is a good question. The reason is we believe it better to fix some obvious
 problems: there were some bugs that would very possibly prevent it from working
-even if it was in i386 linux though Yusuke seemed to get it to work in an
-emulator so perhaps not. Still it’s better to have the type of the file pointer
-correct and so that the file can at least be opened in modern systems even if
-the compiler won’t work there.

-
Also the supplementary program, which did not work at all, was fixed (by Cody)
-and it can be run by itself for fun in modern systems, which was not possible
-before the fixes there.

+even if it was in i386 linux though it did seem to work in an emulator, so
+perhaps not. Still it’s better to have the type of the file pointer correct and
+so that the file can at least be opened in modern systems even if the compiler
+won’t work there.

+
Also the supplementary program, which did not work at all, was fixed and it can
+be run by itself for fun in modern systems, which was not possible before the
+fixes there.

 

 
2001/cheong

 

@@ -2051,9 +2042,7 @@ details and a workaround.

 
Source code: 2001/westley/westley.c

 
Information: 2001/westley/index.html

 
This function uses gets(3) but it would be ideal if it used fgets(3). This
-one is rather complicated and will be looked at later (some progress was made by
-Cody but it is less important than other work) but you are welcome to try
-and fix this if you wish.

+one is rather complicated but you are welcome to try and fix this if you wish.

 
STATUS: main() has only one arg - try and make it have 2 or 3

 
This program only has one arg to main(). However changing it to have 2 is not
 as simple as it might seem. Doing this breaks things. If memory serves changing
@@ -2321,14 +2310,14 @@ for running itself.

 
STATUS: INABIAF - please DO NOT fix

 
Source code: 2005/mynx/mynx.c

 
Information: 2005/mynx/index.html

-
Cody Boone Ferguson notes that, though
-probably obvious, this entry will not work with https. He added an alt version
-that scans for https in case someone wants to set up a pipeline or other
-workaround (perhaps with stunnel) or even add additional code to it to make it
-work with https but the problem otherwise is a secure connection has to first be
-set up in order to give http commands. This is not a bug but it’s worth pointing
-out as it won’t work on as many websites as it used to including the IOCCC
-website itself.

+
Probably this is obvious, but this entry will not work with https. An
+alt version exists that SCANS for https in case someone wants to set up a pipeline or
+other workaround (perhaps with stunnel) or even add additional code to it to
+make it work with https but the problem otherwise is a secure connection has to
+first be set up in order to give http commands. This is not a bug but it’s worth
+pointing out as it won’t work on as many websites as it used to including the
+IOCCC website itself. The author noted that someone did
+make a version that supports https but it is not known where this might be.

 

 
2005/sykes

 

@@ -2434,13 +2423,12 @@ without outputting a solution. If you can wait that long.

 
STATUS: INABIAF - please DO NOT fix

 
Source code: 2006/toledo2/toledo2.c

 
Information: 2006/toledo2/index.html

-
Cody Boone Ferguson fixed this program to
+
This was fixed to
 not crash in macOS (it appeared to work fine in fedora linux on an x86_64
-architecture but he does not know if it crashed in macOS Ventura due to the fact
+architecture but it is not known if it crashed in macOS Ventura due to the fact
 it is an arm64 CPU - the Apple silicon chip, but given that the author later
 made some slight changes to make it not crash in x86_64 macOS that might be
-the case). This fix, BTW, is a mix of a fix by Yusuke
-Endoh and Cody’s.

+the case).

 
Nevertheless there are two features that are not bugs.

 
By design this program is supposed to crash on termination. This actually no
 longer seems to happen but we don’t need this to be added even if it might
@@ -2544,11 +2532,10 @@ a bus error).

 like it might (see Apple resources below) be but it could also be a wider
 problem with macOS. It appears that Apple does not allow certain combinations of
 memory protections with the arm64 processor.

-
Cody Boone Ferguson tried some of the
-workarounds but at this time he could not get it to work. He offers some earlier
-debugging sessions below as well as a resource from the author as well as some
-resources on Apple’s website should anyone wish to take a crack at it. He might
-address it later but a starting point might be in
+
Some of the workarounds have been tried but at this time it did not seem to
+work. Some earlier debugging sessions are below as well as a resource from the
+author as well as some resources on Apple’s website should anyone wish to take a
+crack at it. A starting point might be in
 richards.alt.c.

 
Debugging

 
At first glance it appeared to be that it might be the function pointers or the
@@ -2689,7 +2676,7 @@ Silicon

 Entitlement

 
Looking at
 https://github.com/apple/darwin-xnu/blob/5394bb038891708cd4ba748da79b90a33b19f82e/bsd/kern/kern_mman.c
-Cody noticed a curious thing in the mprotect() function: #if CONFIG_DYNAMIC_CODE_SIGNING and the protection variable has the
+A curious thing is in the mprotect() function: #if CONFIG_DYNAMIC_CODE_SIGNING and the protection variable has the
 VM_PROT_TRUSTED set it might allow overriding the problem but this is
 unconfirmed and it’s not known when CONFIG_DYNAMIC_CODE_SIGNING would be
 defined.

@@ -2945,7 +2932,7 @@ is not. Again see his index.html for details. However it is also possible to not
 rely on the entry as the below shows. One should be able to do:

 
    echo 'No. I want chocolate!' | ./prog > chocolate.raw
 
-./prog e < chocolate.raw

+    ./prog e < chocolate.raw

 
and get:

 
    No. I want some chocolate!

 
but instead we get:

diff --git a/bugs.md b/bugs.md
index bfe394c74..cdf13be11 100644
--- a/bugs.md
+++ b/bugs.md
@@ -69,15 +69,14 @@ might seem to be fine but is actually not! We will note some where this is known
 to happen (if it's not yet fixed). This has actually already happened to us.
 Sometimes it is okay: some entries are known to not work but they can still have
 improvements (rarer situation but it's happened). Some might have slightly
-different output but which is not a problem for instance a newline after output
-in [Cody Boone Ferguson](authors.html#Cody_Boone_Ferguson)'s changing it to
-[1994/ldb](%%REPO_URL%%/1994/ldb/ldb.c) use `fgets()` from `gets()`.
+different output but which is not a problem for instance a newline after output.
+This is not the most ideal but it is okay.
 
 Make **ABSOLUTE CERTAIN** that you read the index.html file _BEFORE_ your changes
 as it's important to see that the code is doing what it is supposed to. In the
 case that it's not obvious (some index.html files do not even have commands to
 try or even explain how to use it!) then you should either skip the entry OR ask
-someone who will know e.g. us.
+someone who will know for instance the Judges.
 
 Make **ABSOLUTE CERTAIN** that you read the next section, the list of statuses
 and the related information, BEFORE you submit a pull request!
@@ -124,14 +123,14 @@ Another type of warning that would be hard to keep track of is different data
 sizes on different platforms.  These tend to be required at the risk that
 sometimes the entry will not work for certain platforms, some of which might or
 might not be fixable; a good example where it was required to change and is okay
-is when [Cody Boone Ferguson](authors.html#Cody_Boone_Ferguson) fixed the
-segfault in macOS of [1989/paul](%%REPO_URL%%/1989/paul/paul.c): changing the `int *` to a
-`long *` was required and it works just as well with linux.
+is the fix of the segfault in macOS of
+[1989/paul](%%REPO_URL%%/1989/paul/paul.c): changing the `int *` to a `long *`
+was required and it works just as well with linux.
 
 But even if they are fixable (which will likely be hard to do) it's almost
 certain that such code would be just as non-portable (importable ? :-) ).
 
-In rare cases they are valid. For instance Cody noticed in linux the following
+In rare cases they are valid. For instance in linux the following
 warning in [1985/applin](%%REPO_URL%%/1985/applin/applin.c) with gcc:
 
 ```
@@ -140,7 +139,7 @@ warning in [1985/applin](%%REPO_URL%%/1985/applin/applin.c) with gcc:
           |                                                                              ^~~~~~
 ```
 
-and this reminded him of his fix to
+and this is is kind of like the fix to
 [1984/anonymous](%%REPO_URL%%/1984/anonymous/anonymous.c). In the case of `1984/anonymous` it
 was a bit more involved but with `1985/applin` one need only add to the Makefile
 `-include unistd.h`. So there are some cases where fixing warnings can fix a
@@ -164,7 +163,7 @@ include you can update the Makefile `CINCLUDE` variable. For instance if it
 needs `stdio.h` you could do `-include stdio.h`. Please leave a space after the
 `=` in the Makefile. You may also have extra long lines if this seems useful to
 make it a one-liner even if it kind of makes it longer than what the judges
-consider a one-liner. Thank you!
+consider a one-liner, at least within reason. Thank you!
 
 
 ### On layout of program source:
@@ -172,9 +171,9 @@ consider a one-liner. Thank you!
 If you make changes _PLEASE TRY AND KEEP THE SOURCE CODE LAYOUT AS CLOSE TO THE
 ORIGINAL AS POSSIBLE_. This might not always be possible and if you have an
 editor that does formatting it can cause problems. Sometimes formatters can even
-break code! [Cody Boone Ferguson](authors.html#Cody_Boone_Ferguson) has
-experienced this many times with vim so he tends to disable all format options
-when formatting code. In vim you should be able to do that with:
+break code! Some have experienced this many times with vim so he tends to
+disable all format options when formatting code. In vim you should be able to do
+that with:
 
 ```
     :set formatoptions=
@@ -261,7 +260,7 @@ compiles but two versions of code it generates does not work with clang.
 
 However some still might have problems of some kind or another and some might
 not yet be located as an additional defect of clang was noticed where `main()`
-is not allowed four args or one arg.
+is not allowed four args or one arg (see below).
 
 This is what the status means, however.
 
@@ -272,26 +271,26 @@ versions have an additional defect where they only allow 0, 2 or 3 args, the
 latter of which affected `1989/westley`, so these entries do not work with
 clang.
 
-[Cody Boone Ferguson](authors.html#Cody_Boone_Ferguson) looked at the source
-code of clang and reported that there is no way to override the requirement of
+Looking at the source
+code of clang, it appears that there is no way to override the requirement of
 arg types so these entries will fail to compile with clang. That's why in some
-entries he fixed he did it by adding a function called `pain()`. :-) He did not
-check for the number of args as that was discovered later but he suspects it's
-the same issue.
+entries the fix was done with a new function, often called `pain()` :-)
 
 **NOTE for macOS users**: please be aware that _gcc_ under macOS **is actually
 clang** despite the fact it might appear to be gcc: no symlink and both gcc and
 clang exist but the gcc is clang which you'll see if you run `gcc --version`.
 
-A tip and some fix methods from Cody: in the older days args to main() not given
-a type were implicit 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](%%REPO_URL%%/1989/tromp/tromp.c) and
-[1986/holloway/holloway.c](1986/holloway/index.html) for two examples though done slightly
-differently). In other cases he was able to dereference the pointers to be used
-like an int and other times a cast was necessary. He used other various
-techniques to get them to compile. In some cases this introduced a problem but
-typically if not always that problem exists with compilers that are less strict.
+A tip and some fix methods from [Cody Boone
+Ferguson](authors.html#[Cody_Boone_Ferguson): in the older days args to main()
+not given a type were implicit ints but when they're required to be `char **`
+this can cause a problem. In some cases it was possible to use a `char *` inside
+`main()` (see [1989/tromp/tromp.c](%%REPO_URL%%/1989/tromp/tromp.c) and
+[1986/holloway/holloway.c](1986/holloway/index.html) for two examples though
+done slightly differently). In other cases it was possible to dereference the
+pointers to be used like an int and other times a cast was necessary. There are
+various techniques to get these to compile. In some cases this introduced a
+problem but typically if not always that problem exists with compilers that are
+less strict.
 
 
 ## STATUS: main() has only one arg
@@ -327,11 +326,9 @@ or if you can `-ggdb3` when compiling as that will help with debugging symbols.
 **Please help us change use of gets() to fgets()**, if possible.
 
 Entries with this status use `gets()` which is unsafe because it has no limit on
-the length of the string. [Cody Boone
-Ferguson](authors.html#Cody_Boone_Ferguson) has fixed several of these and he's
-working on others in between fixing other things.
+the length of the string. Many were fixed but not all.
 
-There's a very good reason for this even though it is bordering on tampering
+There's a very good reason for this change even though it is bordering on tampering
 entries: in modern systems one will get possibly alarming and certainly annoying
 warnings during at least one of compiling, linking and execution. In macOS it's
 most annoying as it happens during execution (also compilation) with the warning
@@ -339,30 +336,30 @@ being interspersed with the output of the program, often causing confusing
 output with the entry. A good example that was fixed is
 [1990/tbr](%%REPO_URL%%/1990/tbr/tbr.c).
 
-Cody provided some important notes on this status with respect to fixing /
-changing entries:
+Some important notes on this status with respect to fixing / changing the
+entries:
 
 0. In some cases changing the entry to use `fgets()` will break the entry and in
-some cases cause it to crash. Where this is known we will document it.  Some of
-these Cody is also off and on working on.
+some cases cause it to crash. Where this is known we will document it.
 
 1. You **MUST** check the output before and after to make sure that it remains
 the same. Sometimes the output might not be immediately obviously wrong but is.
 We will document known examples as we come across them.
 
 2. `gets()` does NOT STORE the `'\n'` but `fgets()` DOES! This is one of the
-reasons some of the entries break when changed to `fgets()`. Cody has fixed some
-of these but there are others he hasn't had time to address or even discover
-yet.
+reasons some of the entries break when changed to `fgets()`. Some of those have
+been fixed but there are others that have not been.
 
 3. Just because you don't see the string `gets` in the code does not mean it's
 not used. It is after all the International _Obfuscated C Code_ Contest!  :-)
 Sometimes it will be in the Makefile and other times it will be obfuscated in
-other ways.  Compilers and linkers tend to warn about its use (and as noted in
-macOS it also happens at execution) and this is a good way to find entries that
-use it even if it's not visible in the code.
+other ways; a good example of that that was fixed is
+[1991/dds](1991/dds/index.html): in this case the string was encrypted.
+Compilers and linkers tend to warn about its use (and as noted in macOS it also
+happens at execution) and this is a good way to find entries that use it even if
+it's not visible in the code.
 
-_NOTE_: this status is _NOT necessarily mutually exclusive_ with the _INABIAF_
+**NOTE**: this status is _NOT necessarily mutually exclusive_ with the _INABIAF_
 (it's not a bug it's a feature) status. The reason for this is due to warnings
 during compiling, linking and/or runtime, sometimes causing confusing output (as
 noted above).
@@ -499,17 +496,18 @@ This program will very likely crash or do something funny without an arg.
 ### Source code: [1984/mullender/mullender.c](%%REPO_URL%%/1984/mullender/mullender.c)
 ### Information: [1984/mullender/index.html](1984/mullender/index.html)
 
-Although there is an alt version and supplementary program added by Cody that
+Although there is an alt version and supplementary program added, that
 will work in modern systems, if you do not have a
 [VAX-11](https://en.wikipedia.org/wiki/VAX-11) or
 [PDP-11](https://en.wikipedia.org/wiki/PDP-11) to run the original entry on it
 will not work. See the index.html for details on the alternate versions.
 
-Cody added and fixed the [gentab.c](%%REPO_URL%%/1984/mullender/gentab.c) which is from the
-author's (or one of them, Mullender) remarks found by Cody. Cody fixed this to
-compile and work (as best as he can determine: he has no VAX-11 or PDP-11 or
-emulator to test it) but running the code on the binary itself produces a
-`short[]` that can compile in modern systems though it'll not work.
+The file [gentab.c](%%REPO_URL%%/1984/mullender/gentab.c) which is from the
+author's (or one of them, Mullender) remarks, was fixed for modern systems, at
+least as best as can be determined: running the code on the binary itself does
+produce a `short[]` that can compile in modern systems but it will not work.
+Before the fix it would fail in some cases and it is possible that in some cases
+it might still fail.
 
 
 

@@ -630,9 +628,11 @@ reverse of other code (also wrt names). See the source file and the index.html
 
 Fixing the (mis)feature is likely to be a very difficult challenge especially
 without breaking something else which is far more likely (see below in tips from
-Cody). You are welcome to try and fix it if you can!
+Cody, who fixed it so the original would compile with `clang` and at least one
+generated version would compile with `clang` too, not compromising the other
+versions with `gcc`). You are welcome to try and fix it if you can!
 
-### Tips from Cody:
+### Tips:
 
 The reason this is crashing is that the array `irk` is being accessed way out of
 bounds by the int `gnat`. For instance:
@@ -651,12 +651,11 @@ bounds by the int `gnat`. For instance:
 The real trouble is that the code is generated and in a complex way or rather
 ways.
 
-I will explain this a little bit (though it might be more than a bit according
-to many :-) ) but that is all I can do for now. The program, when used without
-any args, will print out what it reads. If one arg is specified it will do a
-ROT13 of it. If two args are specified it will print out the text backwards
-(_WITHOUT ROT13!_). If three args are specified it will do both **_reversal AND
-ROT13_**.
+Trying to explain this might be tricky but here is an attempt. The program, when
+used without any args, will print out what it reads. If one arg is specified it
+will do a ROT13 of it. If two args are specified it will print out the text
+backwards (_WITHOUT ROT13!_). If three args are specified it will do both
+**_reversal AND ROT13_**.
 
 So `ver0` is the same as the main program; `ver1` is the ROT13 of the code (but
 see below); `ver2` will reverse the code and `ver3` will both reverse and ROT13
@@ -714,20 +713,18 @@ and then another version that has the reversal _and_ ROT13 then you can see it's
 nigh impossible to fix if not impossible.
 
 The fix to get it to even compile with clang and then get the first two
-(counting the original, `ver0`) to work was the hardest fix I made due to how
-the comments in reverse and ROT13 of it all works together, especially allowing
-all versions to compile with gcc. The only reason that it doesn't work
-completely with clang is the arg types of main() (see if you can figure out how
-the change of `main()` in `westley.c` is not carried over to versions 2 and 3!);
-originally none of them compiled with clang.
+(counting the original, `ver0`) to work was quite hard due to how the comments
+in reverse and ROT13 of it all works together, especially allowing all versions
+to compile with gcc. The only reason that it doesn't work completely with clang
+is the arg types of main() (see if you can figure out how the change of `main()`
+in `westley.c` is not carried over to versions 2 and 3!); originally none of
+them compiled with clang.
 
 But it was possible to get the ROT13 code to compile with clang but the other
 versions, reversed as well as ROT13 and reversed code, proved much more
-problematic. I got it to compile (or maybe mostly compile) all versions with
-clang but I then carried it over to gcc in another system and it had syntax
-errors.
+problematic. It is now possible to compile (or maybe mostly compile) all versions with
+clang but on another system and it had syntax errors.
 
-That's about all I can say for how it works as other things have to be done too.
 Enjoy! :-)
 
 
@@ -819,11 +816,10 @@ This is not considered a bug, however.
 ### Source code: [1990/jaw/jaw.c](%%REPO_URL%%/1990/jaw/jaw.c)
 ### Information: [1990/jaw/index.html](1990/jaw/index.html)
 
-[Cody Boone Ferguson](authors.html#Cody_Boone_Ferguson)
-fixed some issues in this program and [Yusuke
-Endoh](authors.html#Yusuke_Endoh) provided the `btoa`
-script but it appears there is a bug in this entry. The judges wrote that to
-test the entry one can do:
+Some issues in this program were fixed and [Yusuke
+Endoh](authors.html#Yusuke_Endoh) then provided the `btoa` script but it appears
+there is a bug in this entry. The judges wrote that to test the entry one can
+do:
 
 ``` 
     echo "Quartz glyph jocks vend, fix, BMW." | compress | ./btoa | ./jaw
@@ -889,11 +885,11 @@ The authors provided a list of features in the
 ### Source code: [1990/theorem/theorem.c](%%REPO_URL%%/1990/theorem/theorem.c)
 ### Information: [1990/theorem/index.html](1990/theorem/index.html)
 
-[Cody Boone Ferguson](authors.html#Cody_Boone_Ferguson) fixed many bugs that
-prevented this from working properly (including segfaults) but one thing to note
-is that if you pass two zeroes to `theorem_bkp` or `fibonacci` the program
-will enter an infinite loop, printing 0 over and over again; another condition
-where this occurred was fixed but this one should not be fixed. Thank you.
+Many bugs that prevented this from working properly (including segfaults) were
+fixed but one thing to note is that if you pass two zeroes to `theorem_bkp` or
+`fibonacci` the program will enter an infinite loop, printing 0 over and over
+again; another condition where this occurred was fixed but this one should not
+be fixed.
 
 
 

@@ -904,7 +900,7 @@ where this occurred was fixed but this one should not be fixed. Thank you.
 ### Source code: [1990/westley/westley.c](%%REPO_URL%%/1990/westley/westley.c)
 ### Information: [1990/westley/index.html](1990/westley/index.html)
 
-Although Cody fixed this to not enter an infinite loop if the arg (converted to
+Although this was fixed to not enter an infinite loop if the arg (converted to
 a number) is < 0 the lack of an arg check at all was kept in to make it like the
 original. The reason for the < 0 check is it floods the screen (yes this is
 indeed inconsistent with some other entries but it is not worth the time spent,
@@ -969,9 +965,8 @@ when you're cheating it ends up winning! Can you figure that out as well?
 ### Information: [1992/adrian/index.html](1992/adrian/index.html)
 
 The author stated that if the file cannot be opened then it will print a system
-error but this is not the case unless it's showing a fault. However this was
-instead fixed by Cody as part of another problem that was detected so that the
-program just exits 1 if the file cannot be opened.
+error but this is not the case unless it's showing a fault. This was fixed as
+part of another problem that was detected.
 
 Also, if _some_ of the programs are not given an arg they will very likely crash
 or do something funny. For instance `adsleep` and `adbasename`. This is very
@@ -1022,7 +1017,7 @@ Leo Broukhis, before he was an IOCCC judge, sent the IOCCC judges an email:
 
 
 
-A quick debugging session from Cody suggests that the problem with this value
+A quick debugging session suggests that the problem with this value
 is that:
 
 ``` 
@@ -1105,7 +1100,7 @@ debate.
 ### Information: [1992/kivinen/index.html](1992/kivinen/index.html)
 
 When you start the program everything starts to move over to the right side and
-then ends.  [Yusuke Endoh](authors.html#Yusuke_Endoh) pointed out that if you
+then ends. [Yusuke Endoh](authors.html#Yusuke_Endoh) pointed out that if you
 click the mouse it takes it back towards the centre.
 
 If you want to try and fix this, you are welcome to try.
@@ -1119,15 +1114,15 @@ If you want to try and fix this, you are welcome to try.
 ### Source code: [1992/lush/lush.c](%%REPO_URL%%/1992/lush/lush.c)
 ### Information: [1992/lush/index.html](1992/lush/index.html)
 
-We used a patch from [Yusuke Endoh](authors.html#Yusuke_Endoh) to get this to
-work but it only works with gcc. Cody removed the warnings of `gets()` and
-provided a script to run the entry properly.
+This was fixed but it only properly works with gcc; it was also changed to use
+`fgets()` instead of `gets()` and a script was provided to run the entry
+properly. Nonetheless it will only work with gcc.
 
 Unfortunately due to the way the entry works and the fact that other compilers
 like clang have different warnings and errors this simply does not work with
 them.
 
-Some tips from Cody:
+Some tips:
 
 This entry relies on specific compiler warnings. With gcc it will look something
 like:
@@ -1217,7 +1212,7 @@ it yourself through ctrl-c or killing it in some other fashion.
 ### Source code: [1992/westley/westley.c](%%REPO_URL%%/1992/westley/westley.c)
 ### Information: [1992/westley/index.html](1992/westley/index.html)
 
-Cody improved the usability of this program by making it so that as long as the
+The usability of this program was improved by making it so that as long as the
 terminal columns is >= 80 it will display properly, rather than having to wrap
 at 80 columns. However due to the nature of the program if the terminal is < 80
 in column width it will not display right.  To see the number of columns in your
@@ -1392,13 +1387,13 @@ there.
 ### Source code: [1994/ldb/ldb.c](%%REPO_URL%%/1994/ldb/ldb.c)
 ### Information: [1994/ldb/index.html](1994/ldb/index.html)
 
-[Cody Boone Ferguson](authors.html#Cody_Boone_Ferguson) fixed this to compile
-with modern systems but the entry also used `gets(3)` which in some systems would
-print out a warning along with the output of the program. Naturally it could
-also overflow long lines, of which there are many, though that is more
-considered a feature, not a bug, as it was documented by the author.
+This was fixed to compile with modern systems but the entry also used `gets(3)`
+which in some systems would print out a warning along with the output of the
+program. Naturally it could also overflow long lines, of which there are many,
+though that is more considered a feature, not a bug, as it was documented by the
+author.
 
-Cody changed it to `fgets(3)` to prevent the display problem but this introduces
+It was changed to use `fgets(3)` to prevent the display problem but this introduces
 another problem namely that newlines can be printed if the line length < 231.
 
 This seems like a worthy compromise to not have messed up output and although it
@@ -1423,7 +1418,7 @@ for more information on the change to `fgets(3)`.
 even when it works. See the author's remarks in the index.html for details.
 Increasing the buffer size and having it, when fed its own source code,
 generate code that will compile with the same buffer size is difficult: it just
-uses the original size. Cody explains this further down.
+uses the original size. This is explained later down.
 
 Getting it to use `fgets()` is even harder as when fed its own code it will
 generate code that cannot even compile let alone use `fgets(3)`.
@@ -1432,36 +1427,30 @@ In both cases, changing the buffer size and changing it to use `fgets(3)`, will
 cause compilation errors without other adjustments.
 
 See the below magic for details. Along with the author's remarks in the
-index.html file it might prove possible to get it to use `fgets(3)`. Cody,
-writing this on 02 November 2023, only just noticed the author's remarks and
-will later on look at this if nobody takes up the challenge. More important work
-like getting to a place that the next contest can run must be done first.
+index.html file it might prove possible to get it to use `fgets(3)`.
 
-Cody explains the magic of how this entry works, which will be necessary if this
-entry is to be fixed, below.
-
-You might wish to run the command:
-
-``` 
-    make diff_orig_prog
-```
-
-to see what had to change for the buffer size, when looking at the below.
-Furthermore you will want to look at:
+Here is the magic of how this entry works, to help anyone who wishes to work on
+this.
 
+You might wish to run the commands:
 
 ``` 
     diff schnitzi.alt.c schnitzi.alt2.c
+
+    diff schnitzi.alt2.c schnitzi.alt.c
 ```
 
-as the `fgets(3)` version can compile it just can't generate compilable code (let
-alone using `fgets(3)`) when fed itself (to reiterate, just changing the call to
-`fgets(3)` does not mean it can compile and there's a further problem in that
-`fgets(3)` retains the newline whereas `gets(3)` does not). Nevertheless looking
-at these commands will be of help to understand how it works.
+to see how the buffer size and how the `gets(3)` was changed to use `fgets()`,
+in the two alternate versions. Notice that the `fgets(3)` version can compile it
+just can't **generate** compilable code (let alone using `fgets(3)`) when fed
+itself (to reiterate, just changing the call to `fgets(3)` does not mean it can
+compile and there's a further problem in that `fgets(3)` retains the newline
+whereas `gets(3)` does not). Nevertheless looking at these commands will be of
+help to understand how it works, in case one wishes to try and fix it.
 
 For the alternate versions the other functionality is unaffected.
 
+
 ### The magic of [1994/schnitzi](%%REPO_URL%%/1994/schnitzi/schnitzi.c) and how it flips text
 
 The problem is getting the generated code to use `fgets()` (once it even
@@ -1524,9 +1513,9 @@ changing the buffer size, see below).
 Getting this entry to use `fgets(3)` is easy but the problem is you're supposed
 to be able to feed the source to the program and the output of that will be
 compilable. It however will create compiler errors. So it's not just changing
-the code to get it to use `fgets(3)`! I (Cody) already did this before I noticed
-the other part which is why I rolled that part back. I did increase the buffer
-size but that only works on the original source.
+the code to get it to use `fgets(3)`! This was done but
+the other part is why that part was rolled back. The buffer size was increased
+but that only works on the original source.
 
 To say just how sensitive this entry is: even a space, lack of space or a
 character, wrong character, lack of character or character in the wrong place
@@ -1553,7 +1542,7 @@ that's compiled) cannot be opened in the directory it is run from.
 
 ### Important reminder and a note about the `-1` value check for `getc()`:
 
-Cody fixed the code to not use `-1` for the return value of `getc()`; this is
+This code was fixed to not use `-1` for the return value of `getc()`; this is
 important because `EOF` is **NOT** guaranteed to be `-1` but rather any negative
 value. On systems where `EOF != -1` the program would enter an infinite loop
 until the program crashed, by chance reads a `-1` or was killed (it is for this
@@ -1619,8 +1608,7 @@ as documented, are considered features.
 ### Information: [1995/cdua/index.html](1995/cdua/index.html)
 
 This did not originally compile under macOS and after it did compile under
-macOS, it crashed. [Cody Boone Ferguson](authors.html#Cody_Boone_Ferguson)
-fixed these problems.
+macOS, it crashed. These problems were fixed.
 
 It should be noted however that there is a condition where the program will
 prompt you to press return again. This was thought to be a bug but looking at
@@ -1988,7 +1976,7 @@ Another feature that does work in linux is:
 
 Can you help fix these problems?
 
-Cody provided the C code that creates an unformatted perl script that will just
+Here is some C code that creates an unformatted perl script that will just
 print 'unimplemented' for operators but it seems to work in some other ways (see
 below for how to go further than unimplemented) which is the exact perl from the
 C program except that it has the `#!/usr/bin/env perl` and `use warnings;` as
@@ -2097,7 +2085,7 @@ That means then that in linux despite the subroutines seemingly not existing it
 works in the code, at least in some cases.
 
 As far as the unimplemented error goes: the author stated that it means there is
-invalid input. But as can be seen by the input I (Cody) gave the input is not
+invalid input. But as can be seen by the input given, the input is not
 actually incorrect. It is also curious to note that it ends up printing what's
 on the stack at that point:
 
@@ -2107,15 +2095,14 @@ on the stack at that point:
     5
 ```
 
-which might (?) suggest that the `+` operator is unimplemented. Unfortunately it
-has been many years since I have used perl and I was never a guru either.
+which might (?) suggest that the `+` operator is unimplemented.
 
 
 ### STATUS: INABIAF - please **DO NOT** fix
 
 The author states that in perl < 5.6.0 there is a bug with a core dump in what
 they said is in `Perl_sv_upgrade`. As this is documented it is not considered a
-bug to be fixed. For the curious this will crash in macOS. Cody notes that the
+bug to be fixed. For the curious this will crash in macOS. It was noted that the
 code that crashes is:
 
 ``` 
@@ -2224,17 +2211,18 @@ fire](https://en.wikipedia.org/wiki/Halt_and_Catch_Fire_(computing))!
 ### Source code: [2001/anonymous/anonymous.c](%%REPO_URL%%/2001/anonymous/anonymous.c)
 ### Information: [2001/anonymous/index.html](2001/anonymous/index.html)
 
-[Cody Boone Ferguson](authors.html#Cody_Boone_Ferguson) fixed this so that it
-doesn't segfault and then also fixed the functionality of it (but see below).
+This was fixed so that it doesn't segfault and then also fixed the functionality
+of it (but see below).
 
-Cody also fixed the [anonymous.ten.c](%%REPO_URL%%/2001/anonymous/anonymous.ten.c) program
-(it also segfaulted) but notes that it **MUST** be compiled as a **32-bit ELF
+The [anonymous.ten.c](%%REPO_URL%%/2001/anonymous/anonymous.ten.c) program was
+also fixed (it also segfaulted) but note that it **MUST** be compiled as a **32-bit ELF
 binary** so it will NOT work in macOS (for example); if you cannot use `-m32` or
 even if you can but it cannot compile as an ELF binary (not elf binary :-) )
 (but see below) then the `anonymous` program itself will very likely crash if
-you run it on the compiled [anonymous.ten.c](%%REPO_URL%%/2001/anonymous/anonymous.ten.c) but
-if nothing else it will not modify the target executable (this part of the fix
-at least should be correct).
+you run it on the compiled
+[anonymous.ten.c](%%REPO_URL%%/2001/anonymous/anonymous.ten.c); if nothing else
+it will not modify the target executable (this part of the fix at least should
+be correct).
 
 Note also that if you don't specify a file or you specify a non-32-bit ELF file
 this program will very likely crash or do something strange like slaughter the
@@ -2252,28 +2240,27 @@ elves of Imladris :-(
 The author stated that it only works with i386 linux so the fact it doesn't work
 in modern systems is considered a feature and not a bug.
 
-[Cody Boone Ferguson](authors.html#Cody_Boone_Ferguson) fixed an initial
-segfault (trying to open the file) and he also fixed the [supplementary program
-bellard.otccex.c](%%REPO_URL%%/2001/bellard/bellard.otccex.c) but this still crashes in
-systems not i386 linux which is what the author stated.
+An initial segfault was fixed (trying to open the file) and the [supplementary
+program bellard.otccex.c](%%REPO_URL%%/2001/bellard/bellard.otccex.c) was also
+fixed but this still crashes in systems not i386 linux which is what the author
+stated.
 
 The author said that they compiled it with [gcc version
 2.95.2](https://ftp.gnu.org/gnu/gcc/gcc-2.95.2/gcc-everything-2.95.2.tar.gz). We
 don't know if a certain gcc version is necessary but it might be helpful to
 download and compile that version to test it - or it might not.
 
-I (Cody) have no i386 system to test this but perhaps this is why I can't get it
-to work.  Yusuke was able to get this to work with `-m32` but only in an
-emulator.
+Yusuke was able to get this to work with `-m32` but only in an emulator. As
+such, it might be that the changes made should be rolled back but at least now
+the supplementary program will work in modern systems.
 
 On the author's [web page for this program](https://bellard.org/otcc/) it is
 explicitly stated that it requires i386 linux.
 
-There I found what should be a more portable version which is included as
-[otccelf.c](%%REPO_URL%%/2001/bellard/otccelf.c) (after adding some `#include`s and the
-modification by Yusuke noted in the [thanks](thanks-for-help.html)
-file) but it appears this *also* requires i386 linux; indeed looking at the code
-it hard codes paths that are i386 specific to linux.
+There it was found what should be a more portable version which is included as
+[otccelf.c](%%REPO_URL%%/2001/bellard/otccelf.c) (after adding some `#include`s
+and the modification but it appears this *also* requires i386 linux; indeed
+looking at the code it hard codes paths that are i386 specific to linux.
 
 Another point of interest is that the author provided unobfuscated versions
 which might be of value to look at.
@@ -2283,14 +2270,14 @@ which might be of value to look at.
 
 This is a good question. The reason is we believe it better to fix some obvious
 problems: there were some bugs that would very possibly prevent it from working
-even if it was in i386 linux though Yusuke seemed to get it to work in an
-emulator so perhaps not. Still it's better to have the type of the file pointer
-correct and so that the file can at least be opened in modern systems even if
-the compiler won't work there.
+even if it was in i386 linux though it did seem to work in an emulator, so
+perhaps not. Still it's better to have the type of the file pointer correct and
+so that the file can at least be opened in modern systems even if the compiler
+won't work there.
 
-Also the supplementary program, which did not work at all, was fixed (by Cody)
-and it can be run by itself for fun in modern systems, which was not possible
-before the fixes there.
+Also the supplementary program, which did not work at all, was fixed and it can
+be run by itself for fun in modern systems, which was not possible before the
+fixes there.
 
 
 

@@ -2421,9 +2408,7 @@ See also the author's list of bugs [here](2001/schweikh/index.html#bugs).
 ### Information: [2001/westley/index.html](2001/westley/index.html)
 
 This function uses `gets(3)` but it would be ideal if it used `fgets(3)`. This
-one is rather complicated and will be looked at later (some progress was made by
-Cody but it is less important than other work) but you are welcome to try
-and fix this if you wish.
+one is rather complicated but you are welcome to try and fix this if you wish.
 
 
 ### STATUS: main() has only one arg - try and make it have 2 or 3
@@ -2804,14 +2789,14 @@ for running itself.
 ### Source code: [2005/mynx/mynx.c](%%REPO_URL%%/2005/mynx/mynx.c)
 ### Information: [2005/mynx/index.html](2005/mynx/index.html)
 
-[Cody Boone Ferguson](authors.html#Cody_Boone_Ferguson) notes that, though
-probably obvious, this entry will not work with https. He added an alt version
-that scans for https in case someone wants to set up a pipeline or other
-workaround (perhaps with stunnel) or even add additional code to it to make it
-work with https but the problem otherwise is a secure connection has to first be
-set up in order to give http commands. This is not a bug but it's worth pointing
-out as it won't work on as many websites as it used to including the [IOCCC
-website](https://www.ioccc.org) itself.
+Probably this is obvious, but this entry will not work with https. An
+alt version exists that _SCANS_ for https in case someone wants to set up a pipeline or
+other workaround (perhaps with `stunnel`) or even add additional code to it to
+make it work with https but the problem otherwise is a secure connection has to
+first be set up in order to give http commands. This is not a bug but it's worth
+pointing out as it won't work on as many websites as it used to including the
+[IOCCC website](https://www.ioccc.org) itself. The author noted that someone did
+make a version that supports `https` but it is not known where this might be.
 
 
 

@@ -2968,13 +2953,12 @@ without outputting a solution.  If you can wait that long.
 ### Source code: [2006/toledo2/toledo2.c](%%REPO_URL%%/2006/toledo2/toledo2.c)
 ### Information: [2006/toledo2/index.html](2006/toledo2/index.html)
 
-[Cody Boone Ferguson](authors.html#Cody_Boone_Ferguson) fixed this program to
+This was fixed to
 not crash in macOS (it appeared to work fine in fedora linux on an `x86_64`
-architecture but he does not know if it crashed in macOS Ventura due to the fact
+architecture but it is not known if it crashed in macOS Ventura due to the fact
 it is an `arm64` CPU - the Apple silicon chip, but given that the author later
 made some slight changes to make it not crash in `x86_64` macOS that might be
-the case). This fix, BTW, is a mix of a fix by [Yusuke
-Endoh](authors.html#Yusuke_Endoh) and Cody's.
+the case).
 
 Nevertheless there are two features that are not bugs.
 
@@ -3130,11 +3114,10 @@ like it _might_ (see Apple resources below) be but it could also be a wider
 problem with macOS. It appears that Apple does not allow certain combinations of
 memory protections with the arm64 processor.
 
-[Cody Boone Ferguson](authors.html#Cody_Boone_Ferguson) tried some of the
-workarounds but at this time he could not get it to work. He offers some earlier
-debugging sessions below as well as a resource from the author as well as some
-resources on Apple's website should anyone wish to take a crack at it. He might
-address it later but a starting point might be in
+Some of the workarounds have been tried but at this time it did not seem to
+work. Some earlier debugging sessions are below as well as a resource from the
+author as well as some resources on Apple's website should anyone wish to take a
+crack at it. A starting point might be in
 [richards.alt.c](%%REPO_URL%%/2011/richards/richards.alt.c).
 
 
@@ -3326,7 +3309,7 @@ Entitlement](https://developer.apple.com/documentation/bundleresources/entitleme
 
 Looking at
 
-Cody noticed a curious thing in the `mprotect()` function: `#if
+A curious thing is in the `mprotect()` function: `#if
 CONFIG_DYNAMIC_CODE_SIGNING` and the protection variable has the
 `VM_PROT_TRUSTED` set it might allow overriding the problem but this is
 unconfirmed and it's not known when `CONFIG_DYNAMIC_CODE_SIGNING` would be
@@ -3667,7 +3650,7 @@ rely on the entry as the below shows. One should be able to do:
 ``` 
     echo 'No. I want chocolate!' | ./prog > chocolate.raw
 
-./prog e < chocolate.raw
+    ./prog e < chocolate.raw
 ```
 
 and get: