summaryrefslogtreecommitdiff
path: root/FAQ
diff options
context:
space:
mode:
authorJeffrey Walton <noloader@gmail.com>2014-08-18 14:16:24 -0400
committerRich Salz <rsalz@akamai.com>2014-08-19 10:01:40 -0400
commit76b10e13c22681d09567192583c81b296aed279e (patch)
tree8c3daa389b1b438be331b20617820b1711cac4b3 /FAQ
parent3609b02305c3678525930ff9bacb566c0122ea2a (diff)
downloadopenssl-new-76b10e13c22681d09567192583c81b296aed279e.tar.gz
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>
Diffstat (limited to 'FAQ')
-rw-r--r--FAQ23
1 files changed, 11 insertions, 12 deletions
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?