From: Jeffrey Walton Date: Mon, 18 Aug 2014 18:16:24 +0000 (-0400) Subject: PR2401: Typos in FAQ X-Git-Tag: master-post-reformat~477 X-Git-Url: https://git.librecmc.org/?a=commitdiff_plain;h=76b10e13c22681d09567192583c81b296aed279e;p=oweals%2Fopenssl.git PR2401: Typos in FAQ Also rewrite section on compiler bugs; Matt pointed out that it has some grammatical issues. Reviewed-by: Emilia Kasper --- diff --git a/FAQ b/FAQ index 3e23e23de8..445138e38d 100644 --- a/FAQ +++ b/FAQ @@ -412,7 +412,7 @@ whatever name they choose. The ways to print out the oneline format of the DN (Distinguished Name) have been extended in version 0.9.7 of OpenSSL. Using the new X509_NAME_print_ex() interface, the "-nameopt" option could be introduded. See the manual -page of the "openssl x509" commandline tool for details. The old behaviour +page of the "openssl x509" command line tool for details. The old behaviour has however been left as default for the sake of compatibility. * What is a "128 bit certificate"? Can I create one with OpenSSL? @@ -434,7 +434,7 @@ software from the US only weak encryption algorithms could be freely exported inadequate. A relaxation of the rules allowed the use of strong encryption but only to an authorised server. -Two slighly different techniques were developed to support this, one used by +Two slightly different techniques were developed to support this, one used by Netscape was called "step up", the other used by MSIE was called "Server Gated Cryptography" (SGC). When a browser initially connected to a server it would check to see if the certificate contained certain extensions and was issued by @@ -723,16 +723,15 @@ possible alternative might be to switch to GCC. * Test suite still fails, what to do? -Another common reason for failure to complete some particular test is -simply bad code generated by a buggy component in toolchain or deficiency -in run-time environment. There are few cases documented in PROBLEMS file, -consult it for possible workaround before you beat the drum. Even if you -don't find solution or even mention there, do reserve for possibility of -a compiler bug. Compiler bugs might appear in rather bizarre ways, they -never make sense, and tend to emerge when you least expect them. In order -to identify one, drop optimization level, e.g. by editing CFLAG line in -top-level Makefile, recompile and re-run the test. - +Another common reason for test failures is bugs in the toolchain +or run-time environment. Known cases of this are documented in the +PROBLEMS file, please review it before you beat the drum. Even if you +don't find anything in that file, please do consider the possibility +of a compiler bug. Compiler bugs often appear in rather bizarre ways, +they never make sense, and tend to emerge when you least expect +them. One thing to try is to reduce the level of optimization (such +as by editing the CFLAG variable line in the top-level Makefile), +and then recompile and re-run the test. * I think I've found a bug, what should I do?