Ken Moffat wrote:
> On Mon, Jun 17, 2013 at 08:56:35AM +0200, NP wrote:
>> On 13-06-17 03:27, Ken Moffat wrote:

>   The one exception is SSL_shutdown (3).  Nico's patch lists the
> return values as >1, >0, >-1.  My amended patch causes them to be
> listed as 1, 0, <0 (using E<lt>0 which I noticed in one of the other
> pod files).  That look reasonable, but in fact the version on my
> installed system actually says:
>
> RETURN VALUES
>         The following return values can occur:
>
>         1.  The shutdown was successfully completed. The "close
>             notify" alert was sent and the peer's "close notify"
>             alert was received.
>
>         2.  The shutdown is not yet finished. Call
>             SSL_shutdown() for a second time, if a bidirectional
>             shutdown shall be performed.  The output of
>             SSL_get_error(3) may be misleading, as an erroneous
>             SSL_ERROR_SYSCALL may be flagged even though no
>             error occurred.
>
>         3.  -1
>
>             The shutdown was not successful because a fatal
>             error occurred either at the protocol level or a
>             connection failure occurred. It can also occur if
>             action is need to continue the operation for non-
>             blocking BIOs.  Call SSL_get_error(3) with the
>             return value ret to find out the reason.
>
>   To me, that standard version makes less than zero sense : if 1,2,3
> are the order in which possible return codes are listed, what are
> the codes being described ?
>
>   Anyone got any opinions on SSL_shutdown (3), even just a bare "mine
> also says the return values are 1, 2, 3 with -1" ?

I check these with Google:  man SSL_shutdown

A good link is http://unixhelp.ed.ac.uk/CGI/man-cgi?SSL_shutdown+3

Compare with that.

   -- Bruce



-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Reply via email to