In order for makewhatis -M under IRIX 6.5.14m not to fail on
SSL_shutdown.3 as follows:
nroff: Macro argument too long; line 170, file
/usr/local/man/man3/SSL_shutdown.3
stack: N"
I found it necessary (well, at least it was sufficient) to recast the
long
.Ip "...\*(N"...\*(T"..." 4
lines as
.Ip
...\*(L"...\*(R"...
The version is openssl-0.9.6c, in case that should matter. I did not
have to change the corresponding .IX Item lines. A context diff is
attached.
FWIW,
--
Rick Troxel, Helix Systems Staff [EMAIL PROTECTED] 301/435-2983
*** ../SSL_shutdown.3.ORIG Tue Mar 26 14:38:39 2002
--- SSL_shutdown.3 Thu May 9 15:58:29 2002
***************
*** 218,225 ****
.PP
\fISSL_shutdown()\fR supports both uni- and bidirectional shutdown by its 2 step
behaviour.
! .Ip "When the application is the first party to send the \*(N"close notify\*(T"
alert, SSL_shutdown() will only send the alert and the set the
\s-1SSL_SENT_SHUTDOWN\s0 flag (so that the session is considered good and will be kept
in cache). SSL_shutdown() will then return with 0. If a unidirectional shutdown is
enough (the underlying connection shall be closed anyway), this first call to
SSL_shutdown() is sufficient. In order to complete the bidirectional shutdown
handshake, SSL_shutdown() must be called again. The second call will make
SSL_shutdown() wait for the peer's \*(N"close notify\*(T" shutdown alert. On success,
the second call to SSL_shutdown() will return with 1." 4
! .Ip "If the peer already sent the \*(N"close notify\*(T" alert \fBand\fR it was
already processed implicitly inside another function (SSL_read(3)), the
\s-1SSL_RECEIVED_SHUTDOWN\s0 flag is set. SSL_shutdown() will send the \*(N"close
notify\*(T" alert, set the \s-1SSL_SENT_SHUTDOWN\s0 flag and will immediately return
with 1. Whether \s-1SSL_RECEIVED_SHUTDOWN\s0 is already set can be checked using the
SSL_get_shutdown() (see also SSL_set_shutdown(3) call." 4
.PP
It is therefore recommended, to check the return value of \fISSL_shutdown()\fR
and call \fISSL_shutdown()\fR again, if the bidirectional shutdown is not yet
--- 218,227 ----
.PP
\fISSL_shutdown()\fR supports both uni- and bidirectional shutdown by its 2 step
behaviour.
! .Ip
! When the application is the first party to send the \*(L"close notify\*(R" alert,
SSL_shutdown() will only send the alert and the set the \s-1SSL_SENT_SHUTDOWN\s0 flag
(so that the session is considered good and will be kept in cache). SSL_shutdown()
will then return with 0. If a unidirectional shutdown is enough (the underlying
connection shall be closed anyway), this first call to SSL_shutdown() is sufficient.
In order to complete the bidirectional shutdown handshake, SSL_shutdown() must be
called again. The second call will make SSL_shutdown() wait for the peer's \*(L"close
notify\*(R" shutdown alert. On success, the second call to SSL_shutdown() will return
with 1.
! .Ip
! If the peer already sent the \*(L"close notify\*(R" alert \fBand\fR it was already
processed implicitly inside another function (SSL_read(3)), the
\s-1SSL_RECEIVED_SHUTDOWN\s0 flag is set. SSL_shutdown() will send the \*(L"close
notify\*(R" alert, set the \s-1SSL_SENT_SHUTDOWN\s0 flag and will immediately return
with 1. Whether \s-1SSL_RECEIVED_SHUTDOWN\s0 is already set can be checked using the
SSL_get_shutdown() (see also SSL_set_shutdown(3) call."
.PP
It is therefore recommended, to check the return value of \fISSL_shutdown()\fR
and call \fISSL_shutdown()\fR again, if the bidirectional shutdown is not yet
