If the underlying BIO is B<non-blocking>, SSL_connect() will also return
when the underlying BIO could not satisfy the needs of SSL_connect()
-to continue the handshake. In this case a call to SSL_get_error() with the
+to continue the handshake, indicating the problem by the return value -1.
+In this case a call to SSL_get_error() with the
return value of SSL_connect() will yield B<SSL_ERROR_WANT_READ> or
B<SSL_ERROR_WANT_WRITE>. The calling process then must repeat the call after
taking appropriate action to satisfy the needs of SSL_connect().
condition. When using a buffering BIO, like a BIO pair, data must be written
into or retrieved out of the BIO before being able to continue.
-When using a generic method (see L<SSL_CTX_new(3)|SSL_CTX_new(3)>), it
-is necessary to call L<SSL_set_connect_state(3)|SSL_set_connect_state(3)>
-before calling SSL_connect() to explicitly switch the B<ssl> to client
-mode.
-
=head1 RETURN VALUES
The following return values can occur:
=over 4
-=item 1
-
-The TLS/SSL handshake was successfully completed, a TLS/SSL connection has been
-established.
-
=item 0
The TLS/SSL handshake was not successful but was shut down controlled and
by the specifications of the TLS/SSL protocol. Call SSL_get_error() with the
return value B<ret> to find out the reason.
+=item 1
+
+The TLS/SSL handshake was successfully completed, a TLS/SSL connection has been
+established.
+
=item E<lt>0
The TLS/SSL handshake was not successful, because a fatal error occurred either
L<SSL_get_error(3)|SSL_get_error(3)>, L<SSL_accept(3)|SSL_accept(3)>,
L<SSL_shutdown(3)|SSL_shutdown(3)>, L<ssl(3)|ssl(3)>, L<bio(3)|bio(3)>,
L<SSL_set_connect_state(3)|SSL_set_connect_state(3)>,
+L<SSL_do_handshake(3)|SSL_do_handshake(3)>,
L<SSL_CTX_new(3)|SSL_CTX_new(3)>
=cut