From 181bdb90ba1f2361aec5a621c8f1e01736f8cad2 Mon Sep 17 00:00:00 2001
From: Heikki Linnakangas
Date: Mon, 6 Feb 2017 11:33:58 +0200
Subject: Fix typos in comments.

Backpatch to all supported versions, where applicable, to make backpatching
of future fixes go more smoothly.

Josh Soref

Discussion: https://www.postgresql.org/message-id/CACZqfqCf+5qRztLPgmmosr-B0Ye4srWzzw_mo4c_8_B_mtjmJQ@mail.gmail.com
---
 contrib/pgcrypto/pgp-mpi-openssl.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

(limited to 'contrib/pgcrypto/pgp-mpi-openssl.c')

diff --git a/contrib/pgcrypto/pgp-mpi-openssl.c b/contrib/pgcrypto/pgp-mpi-openssl.c
index 24484a6c54..afece26918 100644
--- a/contrib/pgcrypto/pgp-mpi-openssl.c
+++ b/contrib/pgcrypto/pgp-mpi-openssl.c
@@ -74,7 +74,7 @@ bn_to_mpi(BIGNUM *bn)
 }
 
 /*
- * Decide the number of bits in the random componont k
+ * Decide the number of bits in the random component k
  *
  * It should be in the same range as p for signing (which
  * is deprecated), but can be much smaller for encrypting.
@@ -82,8 +82,8 @@ bn_to_mpi(BIGNUM *bn)
  * Until I research it further, I just mimic gpg behaviour.
  * It has a special mapping table, for values <= 5120,
  * above that it uses 'arbitrary high number'.  Following
- * algorihm hovers 10-70 bits above gpg values.  And for
- * larger p, it uses gpg's algorihm.
+ * algorithm hovers 10-70 bits above gpg values.  And for
+ * larger p, it uses gpg's algorithm.
  *
  * The point is - if k gets large, encryption will be
  * really slow.  It does not matter for decryption.
-- 
cgit v1.2.3