From 2341d81ec72f5ae963072957911a67a739a83db9 Mon Sep 17 00:00:00 2001
From: Vaibhav Sagar <vaibhavsagar@gmail.com>
Date: Wed, 6 Mar 2024 19:55:49 +1100
Subject: [PATCH] GHC.Utils.Binary: fix a couple of typos
---
compiler/GHC/Utils/Binary.hs | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/compiler/GHC/Utils/Binary.hs b/compiler/GHC/Utils/Binary.hs
index fa67e83fda22..db28255690b0 100644
--- a/compiler/GHC/Utils/Binary.hs
+++ b/compiler/GHC/Utils/Binary.hs
@@ -597,9 +597,9 @@ getSLEB128 bh = do
-- is to the interface file without the variable length encoding we usually
-- apply.
--- | Encode the argument in it's full length. This is different from many default
+-- | Encode the argument in its full length. This is different from many default
-- binary instances which make no guarantee about the actual encoding and
--- might do things use variable length encoding.
+-- might do things using variable length encoding.
newtype FixedLengthEncoding a
= FixedLengthEncoding { unFixedLength :: a }
deriving (Eq,Ord,Show)
@@ -824,11 +824,11 @@ we stored a tag byte to discriminate between the two cases.
This made some sense as it's highly portable but also not very
efficient.
-However GHC stores a surprisingly large number off large Integer
+However GHC stores a surprisingly large number of large Integer
values. In the examples looked at between 25% and 50% of Integers
serialized were outside of the Int32 range.
-Consider a valie like `2724268014499746065`, some sort of hash
+Consider a value like `2724268014499746065`, some sort of hash
actually generated by GHC.
In the old scheme this was encoded as a list of 19 chars. This
gave a size of 77 Bytes, one for the length of the list and 76
--
GitLab