Index: /trunk/doc/pslib/psLibSDRS.tex
===================================================================
--- /trunk/doc/pslib/psLibSDRS.tex	(revision 344)
+++ /trunk/doc/pslib/psLibSDRS.tex	(revision 345)
@@ -1,3 +1,3 @@
-%%% $Id: psLibSDRS.tex,v 1.17 2004-04-01 02:40:28 price Exp $
+%%% $Id: psLibSDRS.tex,v 1.18 2004-04-01 03:45:02 price Exp $
 \documentclass[panstarrs]{panstarrs}
 
@@ -71,6 +71,6 @@
 astronomical data handling tasks.
 
-PSLib consists of a collection of library function calls -- the
-Application Programming Interfaces (APIs) -- and the associated data
+PSLib consists of a collection of library function calls --- the
+Application Programming Interfaces (APIs) --- and the associated data
 structures.  The capabilities provided by PSLib are grouped into the
 following areas:
@@ -145,5 +145,5 @@
   We need to provide a mechanism for tracking and fixing memory leaks.
   While it is possible to do this by linking with external libraries
-  (e.g.\ Electric Fence, \href{gnu.org}), it is convenient to do so
+  (e.g.\ \href{gnu.org}{Electric Fence}), it is convenient to do so
   within the \PS{} framework.
 
@@ -170,6 +170,6 @@
 
 Within the PSLib memory management system, every allocated memory
-block which is provided to the user is bounded by two additions memory
-segments.  The segment preceeding the user-memory contains data
+block which is provided to the user is bounded by two additional
+memory segments.  The segment preceeding the user-memory contains data
 describing the allocated block, using the \code{psMemBlock} structure.
 The final element of this structure is a \code{void} pointer called
@@ -182,5 +182,5 @@
 requests $N$ bytes of memory, the memory management system in fact
 allocates \code{N + sizeof(psMemBlock) + sizeof(void)} bytes, starting
-at a paricular address, \code{ADDR}.  It then fills in the first
+at a particular address, \code{ADDR}.  It then fills in the first
 \code{sizeof(psMemBlock)} bytes with the data of the \code{psMemBlock}
 structure, and the last \code{sizeof(void)} bytes with the
@@ -189,5 +189,5 @@
 management system reallocates a block of memory, it must also allocate
 the additional space and fill in the boundary values.  If the memory
-management system is give a specific pointer for some operation, it is
+management system is given a specific pointer for some operation, it is
 able to find the corresponding \code{psMemBlock} by simply subtracting
 \code{sizeof(psMemBlock)} from the pointer address.
@@ -199,10 +199,10 @@
 one where the coder mis-counts the range and either fills the data
 just before the start of the valid memory or just after the end of the
-valid memory.  These actions will alter the boundary-post values and
-can be detected by the memory management system.  In the second case,
-hexidecimal dumps of large blocks of memory are easier to examine if
-the value of \code{PS_MEM_MAGIC} is chosen to catch the eye.  A
-traditional value for \code{PS_MEM_MAGIC} is \code{0xdeadbeef} which
-is also easily recognized in a dump of the memory table.  
+valid memory.  These actions will (hopefully) alter the boundary-post
+values, which can be detected by the memory management system.  In the
+second case, hexadecimal dumps of large blocks of memory are easier to
+examine if the value of \code{PS_MEM_MAGIC} is chosen to catch the
+eye.  A traditional value for \code{PS_MEM_MAGIC} is \code{0xdeadbeef}
+which is also easily recognized in a dump of the memory table.
 
 The PSLib memory management system must maintain a private table of
@@ -247,5 +247,5 @@
 deleted.  Valid states are \code{PS_MEM_FREE} and \code{PS_MEM_ALLOC}.
 
-\subsubsection{APIs for Allocation and Freeing}
+\subsubsection{APIs for Allocating and Freeing}
 
 PSLib provides the following APIs to create and destroy memory blocks:
@@ -281,16 +281,16 @@
 \code{malloc}, \code{calloc}, \code{realloc}, or \code{free} will not
 compile.  This may be achieved by defining preprocessor macros which
-mask these functions with invalid statements (\eg{} \code{#define
-malloc(S) for}).  In exceptional cases, such as the memory management
-system itself, programmers may choose to override this prohibition by
-defining the symbol \code{PS_ALLOW_MALLOC}.  Application code will
-call \code{p_psAlloc,p_psRealloc,p_psFree} via the macros defined
-above.
+mask these functions with invalid statements (\eg{} \code{#define malloc(S) for}).
+In exceptional cases, such as the memory management system itself,
+programmers may choose to override this prohibition by defining the
+symbol \code{PS_ALLOW_MALLOC}.  Application code will call
+\code{p_psAlloc,p_psRealloc,p_psFree} via the macros defined above.
   
 The functions \code{psAlloc} and \code{psRealloc} shall never return a
 \code{NULL} pointer. If they are unable to provide the requested
 memory they should attempt to obtain the desired memory by calling the
-routine registered by \code{psMemExhaustedSetCB} (see subsubsection
-\ref{secMemAdvanced}), and if still unsuccessful, call \code{psAbort()}.
+routine registered by \code{psMemExhaustedSetCB} (see
+\S\ref{secMemAdvanced}), and if still unsuccessful, call
+\code{psAbort()}.
 
 Note that we have not specified an equivalent of the \code{calloc}
@@ -340,5 +340,5 @@
 %
 \begin{verbatim}
-typedef void *(*psMemExhaustedCB)(size_t size);
+typedef void (*psMemExhaustedCB)(size_t size);
 psMemExhaustedCB psMemExhaustedCBSet(psMemExhaustedCB func);
 \end{verbatim}
@@ -366,7 +366,7 @@
 are expected.  The callback is for informational purposes only.  Where
 practical and efficient, the memory manager shall call the routine
-registered using the \code{psMemProblemCBSet} whenever a corrupted
-block of memory is discovered.  For example, doubly-freed blocks can
-be detected by checking \code{psMemBlock.refcntr}.
+registered using \code{psMemProblemCBSet} whenever a corrupted block
+of memory is discovered.  For example, doubly-freed blocks can be
+detected by checking \code{psMemBlock.refCounter}.
 
 \subsubsubsection{\tt psMemAllocateCB \& psMemFreeCB}