]> git.ipfire.org Git - thirdparty/openssl.git/commitdiff
Fix new typos found by codespell in documentation
authorDimitri Papadopoulos <3234522+DimitriPapadopoulos@users.noreply.github.com>
Thu, 29 Jun 2023 06:55:12 +0000 (08:55 +0200)
committerPauli <pauli@openssl.org>
Fri, 30 Jun 2023 14:10:15 +0000 (00:10 +1000)
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21322)

doc/designs/fast-param-find.md
doc/designs/quic-design/quic-api-ssl-funcs.md
doc/designs/quic-design/quic-api.md

index 02460ce4bd8ee9282c0fce7d097710d155ca7dac..c69a39aeac9caa63a5f9e43a3f8d954c8f6f08a7 100644 (file)
@@ -102,10 +102,10 @@ THe top level attributes are:
   will be appended _[gs]et[_ctx]_params
 - "functions" is the functions to generate.  By default both setters and
   getters but either can be omitted.
-- "prologue" defines some introductory code emited in the generated functions.
+- "prologue" defines some introductory code emitted in the generated functions.
   Function arguments are: `void *vctx, OSSL_PARAM params[]` and this
   can be used to specialise the void pointer or declare locals.
-- "epilogue" defines some post decode code emited in the generated function
+- "epilogue" defines some post decode code emitted in the generated function
 - "params" defines the parameters both gettable and settable
 
 Within the "params" the fields specify each parameter by label.
index da0eefaf478e4a338fce10d58cd399e379e17052..6ff536b845f152dc2ce62b30ffb46b6fcee3ad82 100644 (file)
@@ -835,7 +835,7 @@ Q&A For TLS-Related Calls
 QUIC always uses AES-128-GCM for Initial packets. At this time the handshake
 layer has not negotiated a ciphersuite so it has no “current” cipher. We could
 return AES-128-GCM here, but it seems reasonable to just return NULL as the
-encryption is mostly for protection against accidential modification and not
+encryption is mostly for protection against accidental modification and not
 “real” encryption. From the perspective of the Handshake layer encryption is not
 active yet. An application using QUIC can always interpret NULL as meaning
 AES-128-GCM is being used if needed as this is implied by using QUIC.
index 2317f54c446d4a82714e789105c8a2295868fb46..c3d21514adc8923b3f9c7d7144a0b7fd3581e73a 100644 (file)
@@ -433,7 +433,7 @@ Should not require any changes.
 | New       | Never         | Yes       | CS            |
 
 Advances the QUIC state machine to the extent feasible, potentially performing
-network I/O. Also compatible with DTLSv1 and supercedes `DTLSv1_handle_timeout`
+network I/O. Also compatible with DTLSv1 and supersedes `DTLSv1_handle_timeout`
 for all use cases.
 
 #### `SSL_get_event_timeout`
@@ -447,7 +447,7 @@ event, if any.
 
 This is similar to the existing `DTLSv1_get_timeout` function, but it is not
 specific to DTLSv1. It is also usable for DTLSv1 and can become a
-protocol-agnostic API for this purpose, superceding `DTLSv1_get_timeout` for all
+protocol-agnostic API for this purpose, superseding `DTLSv1_get_timeout` for all
 use cases.
 
 The design is similar to that of `DTLSv1_get_timeout` and uses a `struct
@@ -1617,7 +1617,7 @@ initial call to `SSL_read` implying use of a remotely-initiated stream. However,
 this would mean we are creating state tracking a remotely-initiated stream
 before the peer has signalled it. This would work in the happy case where the
 client is connected to a compatible server but may result in strange
-inconsistencies of QUIC internal state if a client is accidentially connected to
+inconsistencies of QUIC internal state if a client is accidentally connected to
 an incompatible peer. Since the peer ought to be the authority on the streams it
 creates, this seems like an undesirable approach.