PR2401: Typos in FAQ

Also rewrite section on compiler bugs; Matt pointed out that
it has some grammatical issues.

Reviewed-by: Emilia Kasper <emilia@openssl.org>

diff --git a/FAQ b/FAQ
index 3e23e23de86647b11631e4b36f09d15b6b38df2e..445138e38dd84da757e91d760e7b4dfc38c67541 100644 (file)
--- 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?