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 \*(Nclose 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 \*(Nclose notify\*(T shutdown alert. On success,
the second call to SSL_shutdown() will return with 1. 4
! .Ip If the peer already sent the \*(Nclose 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 \*(Nclose
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 \*(Lclose 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 \*(Lclose
notify\*(R shutdown alert. On success, the second call to SSL_shutdown() will return
with 1.
! .Ip
! If the peer already sent the \*(Lclose 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 \*(Lclose
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
