Format/typo check 1996/schweikh3

1996/schweikh3/README.md

@@ -47,19 +47,19 @@ NOTE: On some systems such as SunOS, one may need to compile with:
 ### Why I think my entry is obfuscated
 
 There are some layout obfuscations that hinder readability, like
-some (but not all) one character tokens in column 1. Includes,
-defines and declarations of data and functions appear intermixed.
-iso646.h is even included in the middle of an expression, how
-disgusting. Besides, requiring iso646.h will render the program
+some (but not all) one character tokens in column 1. `#include`s,
+`#define`s and declarations of data and functions appear intermixed.
+`iso646.h` is even included in the middle of an expression, how
+disgusting. Besides, requiring `iso646.h` will render the program
 uncompilable on many systems that have not yet incorporated
 Amendment One to The Standard.  If you, dear reader, suffer from
-this disease, just read iso646.h.
+this disease, just read `iso646.h`.
 
 There are no `if' statements. They have been replaced by
-"switch () case 1:" or "switch () case 0:" etc. At least one
-switch has a declaration after the opening brace, booh!
-Identifiers are named after random programming languages, Basic,
-Cobol, F77, awk etc.
+`switch () case 1:` or `switch () case 0:` etc. At least one
+`switch` has a declaration after the opening brace, booh!
+Identifiers are named after random programming languages, BASIC (as `Basic`),
+COBOL, F77, awk etc.
 
 You have to select maximum ANSI C conformance of your
 compiler. The source fails to compile under a C++ compiler due to
@@ -94,15 +94,15 @@ The source fails to compile on obsolete systems with obsolete
 memory models due to the identifier `far` (to be honest: this is
 untested :-) ).
 
-Does your indent cope with backslash/newline pairs inbetween
-keywords like in "re\<newline>turn"? Solaris' indent inserts spaces\
-and thereby renders the source uncompilable...
+Does your indent cope with backslash/newline pairs in between keywords like in
+`re\turn` where the `re\` is at the end of a line? ? Solaris' indent inserts
+spaces and thereby renders the source uncompilable...
 
 The indented source will exhibit different semantics when indenting
 changes the number of lines (due to using the `__LINE__` macro in an
 expression).
 
-And what about sizeof `__TIME__`?  This one's for the philosophers\
+And what about `sizeof __TIME__`?  This one's for the philosophers
 and physicists among us programmers. What is it? `sizeof (char *)`? -- no.
 `strlen ("hh:mm:ss")`? -- no. It's the same as `sizeof __DATE__ -
 sizeof "no"` :-)
@@ -114,22 +114,22 @@ possible execution paths.
 ### What this program does
 
 This program tests your operating system's allocation honesty. It
-forks a child that will allocate as much as possible with byte
+forks a child that will allocate as much memory as possible with byte
 granularity and then write to every 1024th byte, at the same time
-writing a status report on stdout. This way each page of the
+writing a status report on `stdout`. This way each page of the
 allocated virtual memory will eventually be referenced. Without
-any arguments, malloc() will be used to allocate memory. If the
-first arg starts with c, calloc() will be used instead.
+any arguments, `malloc(3)` will be used to allocate memory. If the
+first arg starts with `c`, `calloc(3)` will be used instead.
 
 I distinguish three different behaviours:
 
-1. OS without memory overcommit: malloc does not lie -- you can use all memory
+1. OS without memory overcommit: `malloc(3)` does not lie -- you can use all memory
 the OS granted to you.
 
-2. OS with memory overcommit: malloc lies -- any program may get killed at
+2. OS with memory overcommit: `malloc(3)` lies -- any program may get killed at
 random when the OS can not acquire a free page.
 
-3. OS with pseudo memory overcommit: malloc lies -- The OS puts processes to
+3. OS with pseudo memory overcommit: `malloc(3)` lies -- The OS puts processes to
 sleep for which it can not acquire a free page. Because other processes are also
 affected this way, the system slows down and quickly becomes totally unusable
 (also known as "thrashing"). Because more and more processes wait for memory
@@ -137,31 +137,34 @@ returned by other exiting processes the system eventually enters a deadlock
 situation and effectively halts.
 
 I had the pleasure and pain to find all three behaviours on the
-platforms I use regularly. What follows are the outputs for
+platforms I use regularly. 
+
+The file [schweikh3.info](schweikh3.info) has output for
 Solaris, FreeBSD and Linux. The Linux case is interesting in that
-the behaviour changes when calloc is used instead of malloc.
+the behaviour changes when `calloc(3)` is used instead of `malloc(3)`.
 For FreeBSD, the last two lines are not messages stemming from
 my program but issued by the syslog daemon.
 
+
 ### Implementation remarks
 
 How can we distinguish the three different OS types from the
 table above?
 
-Obviously, type 1), no overcommit, is easy.
+Obviously, type (1), no overcommit, is easy.
 
-For type 2), random kill, we need to fork a child that can be killed
+For type (2), random kill, we need to fork a child that can be killed
 and whose exit status the parent collects and decodes. Here's
 where POSIX enters the scene.
 
-Type 3), thrashing, was the hardest part. The first attempt was to
+Type (3), thrashing, was the hardest part. The first attempt was to
 measure the elapsed processor time it takes to write a single byte
 (using `clock()`). If a certain threshold is reached I assume the
 system is thrashing. When thrashing, however, the process does not
 consume processor time in a noticeable amount any longer and I lose.
-So I switched to measuring wall clock time using `time()`. On the one
+So I switched to measuring wall clock time using `time(3)`. On the one
 system that I observe thrashing (Linux) this works (although the
-value returned by time seems to 'hang' sometimes when the OS thrashes.
+value returned by `time(3)` seems to 'hang' sometimes when the OS thrashes.
 Exceeding a threshold of 5 seconds may be detected only after half a
 minute or so.
 

1996/schweikh3/schweikh3.info

@@ -1,6 +1,6 @@
     ***** SOLARIS 2.5 (sparc):
 
-    % prog
+    % schweikh3
     Trying to malloc 2048M+0K+0 bytes..nope
     Trying to malloc 1024M+0K+0 bytes..nope
     Trying to malloc 512M+0K+0 bytes..nope
@@ -41,7 +41,7 @@
 
     ***** FreeBSD 2.1 (i386):
 
-    % prog
+    % schweikh3
     Trying to malloc 2048M+0K+0 bytes..nope
     Trying to malloc 1024M+0K+0 bytes..nope
     Trying to malloc 512M+0K+0 bytes..nope
@@ -82,7 +82,7 @@
     Nov 24 18:11:56 /kernel: swap_pager: out of space
     Nov 24 18:11:57 /kernel: Process 5 killed by vm_fault -- out of swap
 
-    % prog c
+    % schweikh3 c
     Trying to calloc 2048M+0K+0 bytes..nope
     Trying to calloc 1024M+0K+0 bytes..nope
     Trying to calloc 512M+0K+0 bytes..nope
@@ -96,7 +96,7 @@
 
     ***** Linux 1.2.13 (i386):
 
-    % prog
+    % schweikh3
     Trying to malloc 2048M+0K+0 bytes..nope
     Trying to malloc 1024M+0K+0 bytes..nope
     Trying to malloc 512M+0K+0 bytes..nope
@@ -132,7 +132,7 @@
     Able to malloc 23M+1023K+1023 bytes
     23294 kilo bytes ok  malloc lied! Thrashing
 
-    % prog c
+    % schweikh3 c
     Trying to calloc 2048M+0K+0 bytes..nope
     Trying to calloc 1024M+0K+0 bytes..nope
     Trying to calloc 512M+0K+0 bytes..nope