summaryrefslogtreecommitdiff
path: root/contrib/pgcrypto
diff options
context:
space:
mode:
authorHeikki Linnakangas <heikki.linnakangas@iki.fi>2017-02-06 11:33:58 +0200
committerHeikki Linnakangas <heikki.linnakangas@iki.fi>2017-02-06 11:33:58 +0200
commit181bdb90ba1f2361aec5a621c8f1e01736f8cad2 (patch)
tree00678950791dcd1b312418e51b46582a3c9a8b79 /contrib/pgcrypto
parent9863017b87f3592ff663d03fc663a4f1f8fdb8b2 (diff)
downloadpostgresql-181bdb90ba1f2361aec5a621c8f1e01736f8cad2.tar.gz
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
Diffstat (limited to 'contrib/pgcrypto')
-rw-r--r--contrib/pgcrypto/mbuf.c2
-rw-r--r--contrib/pgcrypto/pgp-mpi-internal.c6
-rw-r--r--contrib/pgcrypto/pgp-mpi-openssl.c6
3 files changed, 7 insertions, 7 deletions
diff --git a/contrib/pgcrypto/mbuf.c b/contrib/pgcrypto/mbuf.c
index 44d9adcd2a..73dbfbd08f 100644
--- a/contrib/pgcrypto/mbuf.c
+++ b/contrib/pgcrypto/mbuf.c
@@ -311,7 +311,7 @@ pullf_read_max(PullFilter *pf, int len, uint8 **data_p, uint8 *tmpbuf)
}
/*
- * caller wants exatly len bytes and dont bother with references
+ * caller wants exactly len bytes and don't bother with references
*/
int
pullf_read_fixed(PullFilter *src, int len, uint8 *dst)
diff --git a/contrib/pgcrypto/pgp-mpi-internal.c b/contrib/pgcrypto/pgp-mpi-internal.c
index cb70fcba6c..545009ce19 100644
--- a/contrib/pgcrypto/pgp-mpi-internal.c
+++ b/contrib/pgcrypto/pgp-mpi-internal.c
@@ -141,7 +141,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.
@@ -149,8 +149,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.
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.