From 2eb7e5ff6bb69760f9dd4a43e7e3520ebb930120 Mon Sep 17 00:00:00 2001 From: jmc <> Date: Mon, 26 Dec 2022 07:18:53 +0000 Subject: spelling fixes; from paul tagliamonte i removed the arithmetics -> arithmetic changes, as i felt they were not clearly correct ok tb --- src/lib/libcrypto/engine/README | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'src/lib/libcrypto/engine/README') diff --git a/src/lib/libcrypto/engine/README b/src/lib/libcrypto/engine/README index 6b69b70f57..bc4a9041ff 100644 --- a/src/lib/libcrypto/engine/README +++ b/src/lib/libcrypto/engine/README @@ -122,7 +122,7 @@ use by EVP_MD code. Ditto for tb_rsa.c, tb_dsa.c, etc. These instantiations of ENGINE_TABLE essentially provide linker-separation of the classes so that even if ENGINEs implement *all* possible algorithms, an application using only EVP_CIPHER code will link at most code relating to EVP_CIPHER, tb_cipher.c, core -ENGINE code that is independant of class, and of course the ENGINE +ENGINE code that is independent of class, and of course the ENGINE implementation that the application loaded. It will *not* however link any class-specific ENGINE code for digests, RSA, etc nor will it bleed over into other APIs, such as the RSA/DSA/etc library code. @@ -188,7 +188,7 @@ state will be unchanged. Thus, no cleanup is required unless registration takes place. ENGINE_cleanup() will simply iterate across a list of registered cleanup callbacks calling each in turn, and will then internally delete its own storage (a STACK). When a cleanup callback is next registered (eg. if the cleanup() is -part of a gracefull restart and the application wants to cleanup all state then +part of a graceful restart and the application wants to cleanup all state then start again), the internal STACK storage will be freshly allocated. This is much the same as the situation in the ENGINE_TABLE instantiations ... NULL is the initialised state, so only modification operations (not queries) will cause that -- cgit v1.2.3-55-g6feb