If the underlying BIO is B<non-blocking>, SSL_accept() will also return
when the underlying BIO could not satisfy the needs of SSL_accept()
-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_accept() 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_accept().
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 SSL_set_accept_state()
-before calling SSL_accept() to explicitly switch the B<ssl> to server
-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_connect(3)|SSL_connect(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