From b9e3cc4357ac6ee62764bcd0326e4bd6a54fae2b Mon Sep 17 00:00:00 2001
From: Cody Boone Ferguson <53008573+xexyl@users.noreply.github.com>
Date: Fri, 7 Apr 2023 11:07:06 -0700
Subject: [PATCH] Reword note about gets() in 1992/gson

---
 1992/gson/README.md | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/1992/gson/README.md b/1992/gson/README.md
index bc78dd775..fe90038ae 100644
--- a/1992/gson/README.md
+++ b/1992/gson/README.md
@@ -16,13 +16,14 @@
 
 [Cody Boone Ferguson](/winners.html#Cody_Boone_Ferguson) changed the buffer size
 in such a way that gets() should be safe (theoretically) as it comes from the
-command line.  Ideally `fgets()` would be used but this is a more problematic.
+command line (though it can also read input from stdin after starting the
+program). Ideally `fgets()` would be used but this is a more problematic.
 Previously it had a buffer size of 256 which could easily overflow. In this
 entry `gets()` is used in a more complicated way:  first `m` is set to `*++p` in
 a for loop where `p` is argv. Later `m` is set to point to `h` which was of size
-\256. `gets()` is called as `m = gets(m)`) but trying to change it to use fgets()
-proved more a problem. Since the input must come from the command line Cody
-changed the buffer size to `ARG_MAX+1` which should be enough (again
+\256. `gets()` is called as `m = gets(m)`) but trying to change it to use
+fgets() proved more a problem. Since the input must come from the command line
+Cody changed the buffer size to `ARG_MAX+1` which should be enough (again
 theoretically) especially since the command expects redirecting a dictionary
 file as part of the command line. This also makes it possible for longer strings
 to be read (in case the `gets()` was not used in a loop). Thank you Cody for