In message <> on Thu, 13 Jul 2006 15:59:18 +0200, Jan Pazdziora said:

jpr-ossl> OK. I suggest I prepare a patch that will not change them (they will
jpr-ossl> be IPv4-only), will mark them with #ifndef OPENSSL_NO_DEPRECATED, and
jpr-ossl> will not add them to the .pod. Sounds reasonable?


jpr-ossl> How about the problem of BIO_set_conn_ip/BIO_get_conn_ip being
jpr-ossl> IPv4-only? Do you prefer BIO_set_conn_ipv6/BIO_get_conn_ipv6 as their
jpr-ossl> IPv6-only counterparts, or some other way? How heavily is BIO_* used
jpr-ossl> and how heavily are BIO_set_conn_ip/BIO_get_conn_ip used?

They aren't used at all in OpenSSL itself, as far as I can see. As
for the rest of the world, your guess is as good as mine.

They way they work, I think that IPv6 variants is the way to go.

jpr-ossl> And a third question -- the apps/*.c seem to use BIO_* for some tasks,
jpr-ossl> but some other things they duplicate -- the name resolving and socket
jpr-ossl> setup being a good example. Is there a plan (or a distant future
jpr-ossl> target) to have apps/*.c fully use BIO_*?

There's no specific plan for that. This is one of those times when I
will simply tell you that patches are welcome! :-)

jpr-ossl> I ask these questions to make sure I understand plans of the
jpr-ossl> OpenSSL Team well and that the patches I'm going to prepare
jpr-ossl> will have reasonable chance to be included in the core
jpr-ossl> openssl.

From my point of view, as long as the apps/ stuff gives the same
output for the same input, I have nothing against changes there (as
long as they work all the way). I would be surprised if there was
much protest from anyone else either.


Please consider sponsoring my work on free software.
See for details.

Richard Levitte

"When I became a man I put away childish things, including
the fear of childishness and the desire to be very grown up."
-- C.S. Lewis
__________________________________________________ ____________________
OpenSSL Project
Development Mailing List
Automated List Manager