From: Alessandro Ghedini Date: Thu, 8 Oct 2015 12:40:42 +0000 (+0200) Subject: Fix typos X-Git-Tag: OpenSSL_1_0_2e~46 X-Git-Url: https://git.openssl.org/?a=commitdiff_plain;h=ec3a7c9b3729cd45c550222556100666aedc5bbc;p=openssl.git Fix typos Reviewed-by: Rich Salz Reviewed-by: Richard Levitte (cherry picked from commit d900a015b5a89ea2018e6122dd2738925e4d68ab) --- diff --git a/crypto/aes/asm/aesni-x86.pl b/crypto/aes/asm/aesni-x86.pl index f67df8cf13..9b2e37aafb 100644 --- a/crypto/aes/asm/aesni-x86.pl +++ b/crypto/aes/asm/aesni-x86.pl @@ -88,7 +88,7 @@ $inout3="xmm5"; $in1="xmm5"; $inout4="xmm6"; $in0="xmm6"; $inout5="xmm7"; $ivec="xmm7"; -# AESNI extenstion +# AESNI extension sub aeskeygenassist { my($dst,$src,$imm)=@_; if ("$dst:$src" =~ /xmm([0-7]):xmm([0-7])/) diff --git a/crypto/bn/asm/ia64.S b/crypto/bn/asm/ia64.S index c0cee8211c..a9a42abfc3 100644 --- a/crypto/bn/asm/ia64.S +++ b/crypto/bn/asm/ia64.S @@ -422,7 +422,7 @@ bn_mul_add_words: // This loop spins in 3*(n+10) ticks on Itanium and in 2*(n+10) on // Itanium 2. Yes, unlike previous versions it scales:-) Previous -// version was peforming *all* additions in IALU and was starving +// version was performing *all* additions in IALU and was starving // for those even on Itanium 2. In this version one addition is // moved to FPU and is folded with multiplication. This is at cost // of propogating the result from previous call to this subroutine diff --git a/crypto/sha/asm/sha512-parisc.pl b/crypto/sha/asm/sha512-parisc.pl index fc0e15b3c0..6cad72e255 100755 --- a/crypto/sha/asm/sha512-parisc.pl +++ b/crypto/sha/asm/sha512-parisc.pl @@ -19,7 +19,7 @@ # SHA512 performance is >2.9x better than gcc 3.2 generated code on # PA-7100LC, PA-RISC 1.1 processor. Then implementation detects if the # code is executed on PA-RISC 2.0 processor and switches to 64-bit -# code path delivering adequate peformance even in "blended" 32-bit +# code path delivering adequate performance even in "blended" 32-bit # build. Though 64-bit code is not any faster than code generated by # vendor compiler on PA-8600... # diff --git a/demos/engines/zencod/hw_zencod.c b/demos/engines/zencod/hw_zencod.c index 0c0f524d4c..daf0aef1ef 100644 --- a/demos/engines/zencod/hw_zencod.c +++ b/demos/engines/zencod/hw_zencod.c @@ -610,7 +610,7 @@ static int zencod_init(ENGINE *e) ptr_zencod_rc4_cipher = ptr_rc4_1; /* - * We should peform a test to see if there is actually any unit runnig on + * We should perform a test to see if there is actually any unit runnig on * the system ... Even if the cryptozen library is loaded the module coul * not be loaded on the system ... For now we may just open and close the * device !! diff --git a/doc/crypto/BIO_read.pod b/doc/crypto/BIO_read.pod index b34528104d..2c177f0b6d 100644 --- a/doc/crypto/BIO_read.pod +++ b/doc/crypto/BIO_read.pod @@ -9,9 +9,9 @@ BIO_read, BIO_write, BIO_gets, BIO_puts - BIO I/O functions #include int BIO_read(BIO *b, void *buf, int len); - int BIO_gets(BIO *b,char *buf, int size); + int BIO_gets(BIO *b, char *buf, int size); int BIO_write(BIO *b, const void *buf, int len); - int BIO_puts(BIO *b,const char *buf); + int BIO_puts(BIO *b, const char *buf); =head1 DESCRIPTION @@ -26,7 +26,7 @@ return the digest and other BIOs may not support BIO_gets() at all. BIO_write() attempts to write B bytes from B to BIO B. -BIO_puts() attempts to write a null terminated string B to BIO B +BIO_puts() attempts to write a null terminated string B to BIO B. =head1 RETURN VALUES diff --git a/doc/crypto/BN_rand.pod b/doc/crypto/BN_rand.pod index b3aec96cdc..e8cbf658b4 100644 --- a/doc/crypto/BN_rand.pod +++ b/doc/crypto/BN_rand.pod @@ -19,7 +19,7 @@ BN_rand, BN_pseudo_rand, BN_rand_range, BN_pseudo_rand_range - generate pseudo-r =head1 DESCRIPTION BN_rand() generates a cryptographically strong pseudo-random number of -B bits in length and stores it in B. If B is -1, the +B in length and stores it in B. If B is -1, the most significant bit of the random number can be zero. If B is 0, it is set to 1, and if B is 1, the two most significant bits of the number will be set to 1, so that the product of two such random diff --git a/doc/crypto/EC_GROUP_copy.pod b/doc/crypto/EC_GROUP_copy.pod index 954af469d5..49dc01ced1 100644 --- a/doc/crypto/EC_GROUP_copy.pod +++ b/doc/crypto/EC_GROUP_copy.pod @@ -158,7 +158,7 @@ EC_GROUP_get0_seed returns a pointer to the seed that was used to generate the p specified. EC_GROUP_get_seed_len returns the length of the seed or 0 if the seed is not specified. EC_GROUP_set_seed returns the length of the seed that has been set. If the supplied seed is NULL, or the supplied seed length is -0, the the return value will be 1. On error 0 is returned. +0, the return value will be 1. On error 0 is returned. EC_GROUP_cmp returns 0 if the curves are equal, 1 if they are not equal, or -1 on error. diff --git a/doc/crypto/EC_KEY_new.pod b/doc/crypto/EC_KEY_new.pod index e859689bcb..0fa2de1721 100644 --- a/doc/crypto/EC_KEY_new.pod +++ b/doc/crypto/EC_KEY_new.pod @@ -70,8 +70,8 @@ The functions EC_KEY_get0_group, EC_KEY_set_group, EC_KEY_get0_private_key, EC_K The functions EC_KEY_get_conv_form and EC_KEY_set_conv_form get and set the point_conversion_form for the B. For a description of point_conversion_forms please refer to L. -EC_KEY_insert_key_method_data and EC_KEY_get_key_method_data enable the caller to associate arbitary additional data specific to the -elliptic curve scheme being used with the EC_KEY object. This data is treated as a "black box" by the ec library. The data to be stored by EC_KEY_insert_key_method_data is provided in the B parameter, which must have have associated functions for duplicating, freeing and "clear_freeing" the data item. If a subsequent EC_KEY_get_key_method_data call is issued, the functions for duplicating, freeing and "clear_freeing" the data item must be provided again, and they must be the same as they were when the data item was inserted. +EC_KEY_insert_key_method_data and EC_KEY_get_key_method_data enable the caller to associate arbitrary additional data specific to the +elliptic curve scheme being used with the EC_KEY object. This data is treated as a "black box" by the ec library. The data to be stored by EC_KEY_insert_key_method_data is provided in the B parameter, which must have associated functions for duplicating, freeing and "clear_freeing" the data item. If a subsequent EC_KEY_get_key_method_data call is issued, the functions for duplicating, freeing and "clear_freeing" the data item must be provided again, and they must be the same as they were when the data item was inserted. EC_KEY_set_flags sets the flags in the B parameter on the EC_KEY object. Any flags that are already set are left set. The currently defined standard flags are EC_FLAG_NON_FIPS_ALLOW and EC_FLAG_FIPS_CHECKED. In addition there is the flag EC_FLAG_COFACTOR_ECDH which is specific to ECDH and is defined in ecdh.h. EC_KEY_get_flags returns the current flags that are set for this EC_KEY. EC_KEY_clear_flags clears the flags indicated by the B parameter. All other flags are left in their existing state. diff --git a/doc/crypto/d2i_X509_NAME.pod b/doc/crypto/d2i_X509_NAME.pod index 343ffe1519..b025de7b2f 100644 --- a/doc/crypto/d2i_X509_NAME.pod +++ b/doc/crypto/d2i_X509_NAME.pod @@ -14,7 +14,7 @@ d2i_X509_NAME, i2d_X509_NAME - X509_NAME encoding functions =head1 DESCRIPTION These functions decode and encode an B structure which is the -the same as the B type defined in RFC2459 (and elsewhere) and used +same as the B type defined in RFC2459 (and elsewhere) and used for example in certificate subject and issuer names. Othewise the functions behave in a similar way to d2i_X509() and i2d_X509()