Format/typo check 1992/albert + update bugs.md

There is a known bug in the code that is triggered by some inputs. I
have included some debugging information for those who wish to try and
solve it.

The README.md has been typo/format checked.

This should complete 1992/albert except for hopefully the bug being
resolved in the future.

1992/albert/README.md

@@ -5,6 +5,20 @@ make all
 ```
 
 
+An [alternate version](#alternate-code) exists that fixes a bug.
+
+
+### Bugs and (Mis)features:
+
+The current status of this entry is:
+
+```
+STATUS: known bug - please help us fix
+```
+
+For more detailed information see [1992 albert in bugs.md](/bugs.md#1992-albert).
+
+
 ## To use:
 
 ```sh
@@ -45,12 +59,18 @@ the first factor is 101 and is usually found in an instant.
 The [albert.alt.c](albert.c) file is the fixed file, whereas the
 [albert.c](albert.c) is the file before applying Leo Broukhis' fix.
 
+
+### Alternate build:
+
 To compile this alternate version:
 
 ```sh
 make alt
 ```
 
+
+### Alternate use:
+
 Use `albert.alt` as you would `albert` above.
 
 
@@ -94,7 +114,7 @@ cc albert.c -o 4294967297
 or some such.
 
 There are no data files used, and it is not possible to feed input
-via stdin.
+via `stdin`.
 
 I think this program is a nice example of algorithmic obfuscation.  Several
 times two similar algorithms are merged into one. Then you need quite some
@@ -124,7 +144,7 @@ Here are some hints, but they may not be too helpful:
 82, part 4, a real Dutch treat.  Assembly, C and Forth version have been around
 for some years.
 2. Does fractal programming exist after all?
-3. You remember the ToomCook algorithm in Knuth?  It uses iteration instead of
+3. You remember the Toom-Cook algorithm in Knuth?  It uses iteration instead of
 recursion and is quite jumpy.  This program shares these disadvantages in a
 modified form.
 4. The Conversion is to be found in Knuth, not so the Observation.  The

bugs.md

@@ -760,6 +760,69 @@ you did change it to fprintf, even if you have the right number of args, you'd
 have to remove the outer `()` pair.
 
 
+### STATUS: known bug - please help us fix
+### Source code: [1992/albert/westley.c](1992/westley/westley.c)
+### Information: [1992/albert/README.md](1992/westley/README.md)
+
+Leo Broukhis, before he was an IOCCC judge, sent the IOCCC judges an email:
+
+```
+From: leo _at_ zycad -dot- com (Leo Broukhis)
+Date: Tue, 30 Jan 96 17:37:51 PST
+To: judges _at_ toad -dot- com
+Subject: IOCCC 1992 - a bug
+
+Dear Judges,
+
+albert.c (even in its fixed form) still has a bug. Although I don't
+remember the number that exposed the bug (afair, resulting in coredump)
+in albert.orig.c that has been fixed in albert.c,
+
+I've found a number exposing another bug: 10000000001 (that's 9 0's).
+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
+is that:
+
+```c
+if ( ppp->qq!=48 ) return;
+```
+
+is never reached because the value is never 48 (it is in other cases but not for
+the example input). It varies in value at this point. Observe that the next
+lines of code are:
+
+```c
+while ( ppp->qq==48 )
+{
+    printf("%ld\n",qqq-45);
+    *pp = ppp;
+    ppp = ppp->p;
+}
+
+```
+
+so it is expected that that value is 48, before printing the numbers, but if
+it's not it should not proceed at all, not even to go past that loop. In other
+words that loop should always be entered for at least one iteration. The check
+for the `!= 48` is also required.
+
+Perhaps more useful to know is that at this point in the code the code:
+
+```c
+if ((((( !(aa=setjmp(ppp->ppp))||aa==aaaaaa )))))
+```
+
+appears to be entered because of the return value of `setjmp()`, not the other
+condition.
+
+The alt version does fix the problem but it is not obfuscated and not like the
+entry itself. Can you fix the actual entry? You are welcome to try and do so.
+
+
 ## 1992 gson
 
 ### STATUS: uses gets() - change to fgets() if possible