Use -I to add to @INC, and use -w to produce warnings

[openssl.git] / FAQ

diff --git a/FAQ b/FAQ
index 445138e38dd84da757e91d760e7b4dfc38c67541..0ff792bbc39ca37735ab864c78c72bea89f750a2 100644 (file)
--- a/FAQ
+++ b/FAQ
@@ -133,7 +133,7 @@ OpenSSL.  Information on the OpenSSL mailing lists is available from
 * Where can I get a compiled version of OpenSSL?
 
 You can finder pointers to binary distributions in
-<URL: http://www.openssl.org/related/binaries.html> .
+<URL: http://www.openssl.org/about/binaries.html> .
 
 Some applications that use OpenSSL are distributed in binary form.
 When using such an application, you don't need to install OpenSSL
@@ -789,18 +789,15 @@ considered to be security issues.
 
 * Is OpenSSL thread-safe?
 
-Yes (with limitations: an SSL connection may not concurrently be used
-by multiple threads).  On Windows and many Unix systems, OpenSSL
-automatically uses the multi-threaded versions of the standard
-libraries.  If your platform is not one of these, consult the INSTALL
-file.
+Provided an application sets up the thread callback functions, the
+answer is yes. There are limitations; for example, an SSL connection
+cannot be used concurrently by multiple threads.  This is true for
+most OpenSSL objects.
 
-Multi-threaded applications must provide two callback functions to
-OpenSSL by calling CRYPTO_set_locking_callback() and
-CRYPTO_set_id_callback(), for all versions of OpenSSL up to and
-including 0.9.8[abc...]. As of version 1.0.0, CRYPTO_set_id_callback()
-and associated APIs are deprecated by CRYPTO_THREADID_set_callback()
-and friends. This is described in the threads(3) manpage.
+To do this, your application must call CRYPTO_set_locking_callback()
+and one of the CRYPTO_THREADID_set...() API's.  See the OpenSSL threads
+manpage for details and "note on multi-threading" in the INSTALL file in
+the source distribution.
 
 * I've compiled a program under Windows and it crashes: why?
 
@@ -864,22 +861,25 @@ with the i2d_*_bio() or d2i_*_bio() functions or you can use the
 i2d_*(), d2i_*() functions directly. Since these are often the
 cause of grief here are some code fragments using PKCS7 as an example:
 
+----- snip:start -----
  unsigned char *buf, *p;
- int len;
+ int len = i2d_PKCS7(p7, NULL);
 
- len = i2d_PKCS7(p7, NULL);
- buf = OPENSSL_malloc(len); /* or Malloc, error checking omitted */
+ buf = OPENSSL_malloc(len); /* error checking omitted */
  p = buf;
  i2d_PKCS7(p7, &p);
+----- snip:end -----
 
 At this point buf contains the len bytes of the DER encoding of
 p7.
 
 The opposite assumes we already have len bytes in buf:
 
- unsigned char *p;
- p = buf;
+----- snip:start -----
+ unsigned char *p = buf;
+
  p7 = d2i_PKCS7(NULL, &p, len);
+----- snip:end -----
 
 At this point p7 contains a valid PKCS7 structure or NULL if an error
 occurred. If an error occurred ERR_print_errors(bio) should give more
@@ -896,14 +896,17 @@ because it no longer points to the same address.
 Memory allocation and encoding can also be combined in a single
 operation by the ASN1 routines:
 
- unsigned char *buf = NULL;    /* mandatory */
- int len;
- len = i2d_PKCS7(p7, &buf);
- if (len < 0)
-       /* Error */
+----- snip:start -----
+ unsigned char *buf = NULL;
+ int len = i2d_PKCS7(p7, &buf);
+
+ if (len < 0) {
+     /* Error */
+ }
  /* Do some things with 'buf' */
  /* Finished with buf: free it */
  OPENSSL_free(buf);
+----- snip:end -----
 
 In this special case the "buf" parameter is *not* incremented, it points
 to the start of the encoding.