From 5d0d2892df94e88f6159b9599de7fdecfea9b5e7 Mon Sep 17 00:00:00 2001
From: Ian Gulliver <ian@flamingcow.tv>
Date: Sun, 5 May 2019 23:15:41 +0000
Subject: [PATCH] Remove confusing sentence

---
 2019-05-05-optimistic-parsing.html        | 2 +-
 markdown/2019-05-05-optimistic-parsing.md | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/2019-05-05-optimistic-parsing.html b/2019-05-05-optimistic-parsing.html
index 2603d99..0901887 100644
--- a/2019-05-05-optimistic-parsing.html
+++ b/2019-05-05-optimistic-parsing.html
@@ -20,7 +20,7 @@
 <li>It results in extra system calls, which are <a href="2019-05-05-syscall-efficiency.html">expensive</a></li>
 </ul>
 
-<p>The solution to all three of these is the same: buffering. This can be a dirty word because it hides magic — many programmers have wondered at some point why their output didn't get written, only to discover that they're using <a href="https://en.cppreference.com/w/cpp/io/c/fopen"><code>fopen()</code></a> and didn't write a newline, or similar. Buffering used well, however, can keep execution in user space. Optimistic buffering can make control flow even easier to understand.</p>
+<p>The solution to all three of these is the same: buffering. This can be a dirty word because it hides magic — many programmers have wondered at some point why their output didn't get written, only to discover that they're using <a href="https://en.cppreference.com/w/cpp/io/c/fopen"><code>fopen()</code></a> and didn't write a newline, or similar. Buffering used well, however, can keep execution in user space.</p>
 
 <p>The biggest thing that makes such code ugly is handling running out of data while in the middle of parsing a structure/record. If you have some state (say, a header), preserving that state until the remaining data arrives is messy and error-prone, especially in a many-connections-per-thread model. However, you've already read that data from the socket/buffer, so you can't just throw it away. But what if you had a smarter buffer?</p>
 
diff --git a/markdown/2019-05-05-optimistic-parsing.md b/markdown/2019-05-05-optimistic-parsing.md
index 140844c..1862bba 100644
--- a/markdown/2019-05-05-optimistic-parsing.md
+++ b/markdown/2019-05-05-optimistic-parsing.md
@@ -16,7 +16,7 @@ This pattern presents an implementation challenge: how to balance efficiency wit
 * It only works in a thread-per-connection model
 * It results in extra system calls, which are [expensive](2019-05-05-syscall-efficiency.html)
 
-The solution to all three of these is the same: buffering. This can be a dirty word because it hides magic — many programmers have wondered at some point why their output didn't get written, only to discover that they're using [`fopen()`](https://en.cppreference.com/w/cpp/io/c/fopen) and didn't write a newline, or similar. Buffering used well, however, can keep execution in user space. Optimistic buffering can make control flow even easier to understand.
+The solution to all three of these is the same: buffering. This can be a dirty word because it hides magic — many programmers have wondered at some point why their output didn't get written, only to discover that they're using [`fopen()`](https://en.cppreference.com/w/cpp/io/c/fopen) and didn't write a newline, or similar. Buffering used well, however, can keep execution in user space.
 
 The biggest thing that makes such code ugly is handling running out of data while in the middle of parsing a structure/record. If you have some state (say, a header), preserving that state until the remaining data arrives is messy and error-prone, especially in a many-connections-per-thread model. However, you've already read that data from the socket/buffer, so you can't just throw it away. But what if you had a smarter buffer?