From 90e85992199469ca1191aadd3ab0222a158576be 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-internal.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'contrib/pgcrypto/pgp-mpi-internal.c') diff --git a/contrib/pgcrypto/pgp-mpi-internal.c b/contrib/pgcrypto/pgp-mpi-internal.c index be95f2d0926..daf4594eb7c 100644 --- a/contrib/pgcrypto/pgp-mpi-internal.c +++ b/contrib/pgcrypto/pgp-mpi-internal.c @@ -139,7 +139,7 @@ bn_to_mpi(mpz_t *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. @@ -147,8 +147,8 @@ bn_to_mpi(mpz_t *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