Change bold code snippets to inline code blocks

14-01.md

@@ -71,7 +71,7 @@ information, you may want to refer to the discussion of string searching
 in the excellent *Algorithms in C,* by Robert Sedgewick
 (Addison-Wesley), which served as the primary reference for this
 chapter. (If you look at Sedgewick, be aware that in the Boyer-Moore
-listing on page 288, there is a mistake: "j \> 0" in the **for** loop
+listing on page 288, there is a mistake: "j \> 0" in the `for` loop
 should be "j \>= 0," unless I'm missing something.)
 
 String searching is the simple matter of finding the first occurrence of
@@ -80,7 +80,7 @@ bytes (the buffer). The obvious, brute-force approach is to try every
 possible match location, starting at the beginning of the buffer and
 advancing one position after each mismatch, until either a match is
 found or the buffer is exhausted. There's even a nifty string
-instruction, **REPZ CMPS,** that's perfect for comparing the pattern to
+instruction, `REPZ CMPS`, that's perfect for comparing the pattern to
 the contents of the buffer at each location. What could be simpler?
 
 We have some important information that we're not yet using, though.
@@ -91,10 +91,10 @@ usually be even, neither will any one character constitute half the
 buffer, or anything close. A reasonable conclusion is that the first
 character of the pattern will rarely match the first character of the
 buffer location currently being checked. This allows us to use the
-speedy **REPNZ SCASB** to whiz through the buffer, eliminating most
-potential match locations with single repetitions of **SCASB.** Only
+speedy `REPNZ SCASB` to whiz through the buffer, eliminating most
+potential match locations with single repetitions of `SCASB`. Only
 when that first character does (infrequently) match must we drop back to
-the slower **REPZ CMPS** approach.
+the slower `REPZ CMPS` approach.
 
 It's important to understand that we're assuming that the buffer is
 typical text. That's what I meant at the outset, when I said that the
@@ -106,26 +106,26 @@ information you need may be under your nose.
 > a great deal of useful, if somewhat imprecise, information.
 
 If the buffer contains the letter ‘A' repeated 1,000 times, followed by
-the letter ‘B,' then the **REPNZ SCASB/REPZ CMPS** approach will be much
-slower than the brute-force **REPZ CMPS** approach when searching for
-the pattern "AB," because **REPNZ SCASB** would match at every buffer
+the letter ‘B,' then the `REPNZ SCASB/REPZ CMPS` approach will be much
+slower than the brute-force `REPZ CMPS` approach when searching for
+the pattern "AB," because `REPNZ SCASB` would match at every buffer
 location. You could construct a horrendous worst-case scenario for
 almost any good optimization; the key is understanding the usual
 conditions under which your code will work.
 
 As discussed in Chapter 9, we also know that certain characters have
 lower probabilities of matching than others. In a normal buffer, ‘T'
-will match far more often than ‘X.' Therefore, if we use **REPNZ SCASB**
+will match far more often than ‘X.' Therefore, if we use `REPNZ SCASB`
 to scan for the least common letter in the search string, rather than
 the first letter, we'll greatly decrease the number of times we have to
-drop back to **REPZ CMPS,** and the search time will become very close
-to the time it takes **REPNZ SCASB** to go from the start of the buffer
+drop back to `REPZ CMPS`, and the search time will become very close
+to the time it takes `REPNZ SCASB` to go from the start of the buffer
 to the match location. If the distance to the first match is N bytes,
-the least-common **REPNZ SCASB** approach will take about as long as N
-repetitions of **REPNZ SCASB.**
+the least-common `REPNZ SCASB` approach will take about as long as N
+repetitions of `REPNZ SCASB`.
 
-At this point, we're pretty much searching at the speed of **REPNZ
-SCASB.** On the x86, there simply is no faster way to test each
+At this point, we're pretty much searching at the speed of `REPNZ
+SCASB`. On the x86, there simply is no faster way to test each
 character in turn. In order to get any faster, we'd have to check fewer
 characters—but we can't do that and still be sure of finding all
 matches. Can we?