Normal quotes

15-02.md

@@ -9,7 +9,7 @@
        the head-of-list pointer is required.  Returns the same pointer
        that was passed in. */
 
-    #include “llist.h”
+    #include "llist.h"
     struct LinkNode *DeleteNodeAfter(struct LinkNode *NodeToDeleteAfter)
     {
        NodeToDeleteAfter->NextNode =
@@ -41,7 +41,7 @@
        indicated node. List is headed by a head-of-list pointer; if the
        pointer to the node to delete after points to the head-of-list
        pointer, special handling is performed. */
-    #include “llist.h”
+    #include "llist.h"
     struct LinkNode *DeleteNodeAfter(struct LinkNode **HeadOfListPtr,
        struct LinkNode *NodeToDeleteAfter)
     {
@@ -56,7 +56,7 @@
        return(NodeToDeleteAfter);
     }
 
-However, it is true that if you’re going to store a variety of types of
+However, it is true that if you're going to store a variety of types of
 structures in your linked lists, you should start each node with the
 **LinkNode** field. That way, the link pointer is in the same place in
 *every* structure, and the same linked list code can handle all of the
@@ -65,18 +65,18 @@ This is a less than elegant approach, but it works. C++ can handle data
 mixing more cleanly than C, via derivation from a base link-node class.
 
 Note that Listings 15.1 and 15.3 have to specify the linked-list delete
-operation as “delete the *next* node,” rather than “delete this node,”
-because in order to relink it’s necessary to access the **NextNode**
-field of the node preceding the node to be deleted, and it’s impossible
+operation as "delete the *next* node," rather than "delete this node,"
+because in order to relink it's necessary to access the **NextNode**
+field of the node preceding the node to be deleted, and it's impossible
 to backtrack in a singly linked list. For this reason, singly-linked
 list operations tend to work with the structure preceding the one of
 interest—and that makes the problem of having to special-case the head
 pointer all the more acute.
 
-Similar problems with the head pointer crop up when you’re inserting
-nodes, and in fact in all link manipulation code. It’s easy to end up
+Similar problems with the head pointer crop up when you're inserting
+nodes, and in fact in all link manipulation code. It's easy to end up
 working with either pointers to pointers or lots of special-case code,
-and while those approaches work, they’re inelegant and inefficient.
+and while those approaches work, they're inelegant and inefficient.
 
 ### Dummies and Sentinels {#Heading4}
 
@@ -84,13 +84,13 @@ A far better approach is to use a *dummy node* for the head of the list,
 as shown in Figure 15.2. I invented this one for myself the next time I
 encountered linked lists, while designing a seed fill function for
 MetaWindows, back during my tenure at Metagraphics Corp. But I could
-have learned it by spending five minutes with Sedgewick’s book.
+have learned it by spending five minutes with Sedgewick's book.
 
 ![](images/15-02.jpg)\
  **Figure 15.2**  *Using a dummy head and tail node with a linked list.*
 
   ------------------- -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
-  ![](images/i.jpg)   *The next-node pointer of the head node, which points to the first real node, is the only part of the head node that’s actually used. This way the same code works on the head node as on the rest of the list, so there are no special cases.*
+  ![](images/i.jpg)   *The next-node pointer of the head node, which points to the first real node, is the only part of the head node that's actually used. This way the same code works on the head node as on the rest of the list, so there are no special cases.*
   ------------------- -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 
 Likewise, there should be a separate node for the tail of the list, so
@@ -120,7 +120,7 @@ value has to perform two tests in the inner loop, as shown in Listing
         NULL pointer if no such value was found. Assumes the list is
         terminated with a tail node pointing to itself as the next node. */
     #include <stdio.h>
-    #include “llist.h”
+    #include "llist.h"
     struct LinkNode *FindNodeBeforeValueNotLess(
        struct LinkNode *HeadOfListNode, int SearchValue)
     {
@@ -140,10 +140,10 @@ value has to perform two tests in the inner loop, as shown in Listing
 Suppose, however, that we make the tail node a *sentinel* by giving it a
 value that is guaranteed to terminate the search, as shown in Figure
 15.4. The list in Figure 15.4 has a sentinel with a value field of
-32,767; since we’re working with integers, that’s the highest possible
+32,767; since we're working with integers, that's the highest possible
 search value, and is guaranteed to satisfy any search that comes down
 the pike. The success or failure of the search can then be determined
-outside the loop, if necessary, by checking for the tail node’s special
+outside the loop, if necessary, by checking for the tail node's special
 pointer—but the inside of the loop is streamlined to just one test, as
 shown in Listing 15.5. Not all linked lists lend themselves to
 sentinels, but the performance benefits are considerable for those lend